Chapter 6: Databases

Technically database systems are applications that run on top of the operating system and should not be of direct concern to us as system administrators. That is an excellent theory. In the real-world, databases are tightly tied to the operating system, tend to be general knowledge items, require deep technical knowledge, and relatively little overall time. Because of this it almost universally makes sense that database management duties fall to system administrators; this is especially true on Linux distributions today because most databases that we are likely to use are bundled with the operating system itself.

In this chapter we are going to learn about the following:

• Separating a Database from a DBMS
• Comparing Relational and NoSQL Databases
• Discovering Common Databases on Linux
• Understanding Database Replication and Data Protection Concepts

In the good ol' days system administration and database administration were almost...

Separating a Database from a DBMS

As with most things in life, the terminology used casually around databases is often inaccurate with highly technical and specific terms being used to primarily refer to something different than what the term is meant to describe. But by digging into what a database truly is and how they almost universally work, and by building up correct semantics around the topic, we are going to build a nearly intrinsic understanding of database needs from a system administration perspective. This is often true, simply finding an accurate way to describe a thing allows us to understand it. Databases are not magic, but too often are treated as such.

The Database

We have to begin by asking what a database is. A database is defined by the Oxford Dictionary as a structured set of data held in a computer, especially one that is accessible in various ways. Well that does not tell us very much. But, in a way, it kind of does. Databases cannot be unstructured; this...

Comparing relational and NoSQL databases

Databases come in two major categories: Relational and NoSQL. These are terrible categories, but sadly it is how the world sees databases. These terms are truly awful for several reasons. First because NoSQL is a reference to being not-relational. Which means that databases are either relational or not relational. That's pretty bad taxonomy right there. But it gets worse. SQL is the structured query language commonly associated with relational databases; it was a language written for querying relational databases. So, the term NoSQL refers to non-relational databases, but that's like trying to refer to people who aren't from England by calling them non-English speakers. The two can overlap, but often do not.

SQL is not some intrinsic language of relations; it is just a common convention used to query them. You can make a relational database that cannot use SQL language queries and just as easily you can make a non-relational...

Discovering common databases on Linux

Most operating systems have one or two really popular, key database products associated with them. On Windows this is Microsoft SQL Server, for example. Linux is very different in this regard. Not only is one singular database product not closely ideologically associated with the operating system, but there is typically a plethora of database options available already included in nearly every Linux distribution. This makes it so much more challenging to be prepared to be a Linux system administrator because the expectation that you are knowledgeable of and ready to manage any number of various database products exists. Your theoretical Windows system administrator counterpart would, culturally, need only have knowledge of one very predictable product to claim base knowledge of the entire field. Many databases can run on Windows, but anything other than MS SQL Server is considered an oddity and specialized knowledge. There would never be an expectation...

Understanding database replication and data protection concepts

From the perspective of the Linux system administrator, nothing is going to be as important as database protection which includes, just as it does with systems in general, both disaster avoidance and disaster recovery. Because databases are so critical, and because they are so common, and additionally because their needs are so different from what we typically encounter otherwise in our systems, we are breaking them out here so that we can tackle the nearly unique needs of the database world with respect to data protection.

Because databases store structured data, they come with all of the challenges to protect what we face with heavily used storage systems, which they effectively are. Because databases are highly stateful we must be very careful that we do not break state when looking at data protection.

What does all of this mean in the simplest of terms? Basically, databases are all about storing data and to do...

Summary

Databases are pretty much the most important thing that we will need to work with as system administrators. Whether we run the database ourselves, or only administer the operating system on which they run, they will require more of our attention and will cause us more stress than pretty much anything else that we will do. Our skills and expertise will matter most when working with databases and it is here that the greatest range of our skills will likely be tested.

Wherever we have databases running or in use we need to evaluate how the data is stored on disk, how we can ensure consistency, and how that consistent data can be moved to a backup location whether tape, online, or other. This is probably the single most important task that we will do in system administration, Linux or otherwise.

Our best practices around databases really focus on data protection. We would love to talk about how we should choose the right database type for the job that we will be performing...