MariaDB – Continuous Availability

Is it possible to have continuous availability in your data layer?

It is critical to almost every organisation that their data is available and serves the needs of the business and customers at every moment of every day.

The 9’s of Uptime

Many people claim they have five 9’s of uptime and then a few minutes later, talk about the downtime they needed to carry out maintenance. Five 9’s is 5.26 minutes of downtime!

Losing data, or the unavailability of data is also considered downtime.

Hardware

Hardware needs to have failsafe and redundancy built in.

For example:

• Multiple power supplies – both internal and external power supplies, fed via independent Uninterruptible Power Supplies.
• Network interfaces – multiple interface cards should be connected to independent switches that are fed by separate power supplies, connected to – if necessary – multiple outbound internet connections.
• Disks – utilising RAID or other types of network-attached storage.

In case of a physical server failure, we could migrate to a new host by using a virtualisation layer. However, this process may result in downtime while the server and storage are being migrated.

Hosting

Hosting servers in an office cupboard is no longer a common practice. It’s crucial to choose the right location for optimal availability.

Many organisations choose to share hosting environments or rent a full, half, or quarter rack to host their equipment. Some prefer to use cloud vendors. However, if all your servers, whether physical or virtual, are located in one physical site, an outage at that site will cause your service to become unusable. To prevent this, it is recommended to use multiple servers in different locations.

Cost

Duplicating equipment, hosting locations, and server resources can be expensive. However, with careful planning, the cost does not have to be excessive. Investing money is necessary to achieve higher availability.

Five 9’s of MariaDB Databases

If we concentrate on the database aspect of our infrastructure and assume you have a highly available hardware implementation in place, it is feasible to achieve near 100% uptime of your database cost-effectively.

MariaDB Enterprise

It would be a bold decision for any CEO, CTO, or CIO to invest in a highly available hardware architecture and then run a database without proper support. While many cloud hosting companies offer MariaDB and make several promises, the fact is that you get a community version without actual database support. They may provide some basic failover or hardware migration, but if you encounter an issue within the database, you are on your own. To keep your database running smoothly, it is essential to invest in MariaDB Enterprise, which comes with a support agreement and various SLAs for database availability. Running unsupported software is not advisable for serious enterprises.

MariaDB MaxScale

MariaDB offers a product called MaxScale, which is often referred to as a ‘proxy’, but this description is not entirely accurate. MaxScale is a highly sophisticated tool that enables Open Source databases to compete in the Enterprise space. It can provide high availability, automatic failover, transaction replay, scalability and security benefits to your MariaDB installation. On top of this, MaxScale can also act as a gateway into your database for CDC, Kafka streams and even NoSQL queries.

Continuous Availability of MariaDB

To ensure an uninterrupted database layer, it is recommended to use a carefully planned hardware and hosting structure, along with a Galera, asynchronous, or semi-synchronous cluster of database servers, alongside MariaDB MaxScale.

Your database layer should be set up over at least two locations, such as cloud providers, co-location or physical facilities, or even a hybrid of these locations. It is important to note that a cluster of database nodes should always have a minimum of three, and MaxScale should always have a minimum of two to avoid a single point of failure. This should be duplicated in each physical location.

For the ultimate Continuous Availability, it is recommended to have a minimum of six database nodes, four MaxScale servers, and two highly available locations for hosting, making it an ideal option for most organisations.

How to build?

I have written several blogs on this topic. If you want to build a set of replica servers with MaxScale, you can refer to this blog. To add additional MaxScale servers, you can check out this blog. Lastly, if you wish to use a Java Connector that can maintain a continuous connection to multiple MaxScale servers, then you can read about it here.

With this configuration, you can take a database server or MaxScale server offline. You can upgrade the Operating System and the database software, apply security patches, migrate servers to new hardware or survive the failure of a physical server.

With a MariaDB connector that supports multiple servers, we can provide a list of MaxScale servers. In case of a connection failure, the connection will automatically attempt to connect to the next available server.

Testing

To test what happens when we take one of our MariaDB MaxScale servers offline, you can use my example simple Java Application to connect to the pair of MaxScale servers running with Cooperative Monitoring.

While the script is running, stop MaxScale on the first server, and your application will continue to run.

systemctl stop maxscale

restart maxscale:

systemctl start maxscale

and stop MaxScale on the second server:

systemctl stop maxscale

Your application should still run.

If you stop MaxScale on both servers your application will fail, as there are no servers to connect to.

You can also test your database servers as discussed here. You can stop, start, update and even rebuild a database server, without your application ever stopping.

Test it and let me know how you get on!