Ubuntu Server 18.04 – Preparations for setting up a database server

Getting Started with the IIS Manager in IIS

Before we get started with setting up our database server, there are a few odds and ends to get out of the way. As we go through this chapter, we’ll set up a basic database server using MariaDB. I’m sure more than a few of you are probably familiar with MySQL. MySQL is a tried and true solution which is still in use in many data centers today, and that will probably continue to be the case for the foreseeable future. There’s a good chance that a popular website or two that you regularly visit utilizes it on the backend. So, you may be wondering then, why not go over that instead of MariaDB?

There are two reasons why this tutorial will focus on MariaDB. First, the majority of the Linux community is migrating over to it (more on that later), and it’s also a drop-in replacement for MySQL. This means that any databases or scripts you’ve already written for MySQL will most likely work just fine with MariaDB, barring some edge cases. In reverse, the commands you practice with MariaDB should also function as you would expect on a MySQL server. This is great, considering that many MySQL installations are still in use in many data centers, and you’ll be able to support those too. For the most part, there are very few reasons to stick with MySQL when your existing infrastructure can be ported over to MariaDB, and that’s the direction the Linux community is headed toward anyway.

Why the change? If you were paying attention to the news in the open source community over the last several years, you may have seen articles from time to time regarding various distributions switching to MariaDB from MySQL. Red Hat is one such example; it switched to MariaDB in version 7 of Red Hat Enterprise Linux. Other distributions, such as Arch Linux and Fedora, went the same route. This was partly due to a lack of trust in Oracle, the company that now owns MySQL. When Oracle became the owner of MySQL, there were some serious questions raised in the open source community regarding the future of MySQL as well as its licensing. The Linux community, in general, doesn’t seem to trust Oracle as a company, and in turn doubts its stewardship of MySQL. I’m not going to get into any speculation about Oracle, the future of MySQL, or any conspiracies regarding its future since it’s not relevant to this tutorial (and I’m not a fan of corporate drama). The fact, though, is that many distributions are moving toward MariaDB, and that seems to be the future. It’s a great technology, and I definitely recommend it over MySQL for several reasons.

MariaDB is more than just a fork of MySQL. On its own, it’s a very competent database server. The fact that your existing MySQL implementations should be compatible with it eases adoption. But more than that, MariaDB makes some very worthwhile changes and improvements to MySQL that will only benefit you. Everything you love about MySQL can be found in MariaDB, plus some cutting edge features that are exclusive to it. Some of the improvements in MariaDB include the fact that we’ll receive faster security patches (since developers don’t need to wait for approval from Oracle before releasing updates), as well as better performance. But, even better, is the fact that MariaDB features additional clustering options that are leaps and bounds better and more efficient than plain old MySQL.

So hopefully I’ve sold you on the value of MariaDB. Ultimately, whether or not you actually use it will depend on the needs of your organization. I’ve seen some organizations opt to stick with MySQL, if only for the sole reason that it’s what they know, and new technologies tend to scare management. I can understand that if a solution has proven itself in your data center, there’s really no reason to change if your database stack is working perfectly fine the way it is. To that end, while I’ll be going over utilizing MariaDB, most of my instructions should work for MySQL as well.

With regards to your server, a good implementation plan is key (as always). I won’t spend too much time on this aspect, since by now I know you’ve probably been through a paragraph or two in this tutorial where I’ve mentioned the importance of redundancy (and I’m sure I’ll mention redundancy again a few more times before the last page). At this point, you’re probably just setting up a lab environment or test server on which to practice these concepts before using your new found skills in production. But when you do eventually roll out a database server into production, it’s crucial to plan for long-term stability. Database servers should be regularly backed up, redundant (there I go again), and regularly patched. Later on in this chapter, I’ll walk you through setting up a slave database server, which will take care of the redundancy part. However, that’s not enough on its own, as regular backups are important. There are many utilities that allow you to do this, such as mysqldump, and also snapshots of your virtual machine (assuming you’re not using a physical server). Both solutions are valid, depending on your environment. As someone who has lost an entire work day attempting to resurrect a fallen database server for a client (of which they had no backups or redundancy) my goal is simply to spare you
that headache.

As far as how much resources a database server needs, that solely depends on your environment. MariaDB itself does not take up a huge amount of resources, but as with MySQL, your usage is dependent on your workload. Either you’ll have a few dozen clients connecting, or a few thousand or more. But one recommendation I’ll definitely make is to use LVM for the partition that houses your database files. This will certainly spare you grief in the long run. As we’ve discussed in Chapter 3, Managing Storage Volumes, LVM makes it very simple to expand a filesystem, especially on a virtual machine. If your database server is on a virtual machine, you can add a disk to the volume group and expand it if your database partition starts to get full, and your customers will never notice there was ever about to be a problem. Without LVM, you’ll need to shut down the server, add a new volume, rsync your database server files over to the new location, and then bring up the server. Depending on the size of your database, this situation can span hours. Do yourself a favor, use LVM.

With that out of the way, we can begin setting up MariaDB. For learning and testing purposes, you can use pretty much any server you’d like, physical, virtual, or VPS. Once you’re ready, let’s move on and we’ll get started!

Comments are closed.