Key Differences Between Clustrix and MySQL

Clustrix vs. MySQL

I’m Nick Lamb, and I’m a Support Engineer at Clustrix. I’ve been with Clustrix for over five years.  It’s been exciting and inspirational to watch our company grow in that time, but even more exciting to help and watch our customers accomplish great things using Clustrix as part of their infrastructure. While Clustrix is a MySQL compatible database, there are some key differences between Clustrix and MySQL. In this post, I’ll highlight a few of the most common Clustrix questions I hear from customers.

Are there configuration files in Clustrix?

Clustrix does not have an /etc/my.cnf file like MySQL, or any similar local configuration files. All configuration variables are stored in the database and are automatically read by all nodes. This means that network configuration, master and slave configurations, timeout variables, logging variables, etc. are accessible from every node. These are all stored in the system database as entries in tables or as global variables, meaning you won’t have to restart the database to make configuration changes (an aspect our customers really love).

The best example of this is setting up a master binlog. Just create a binlog by issuing the CREATE BINLOG statement and then simply run the CHANGE MASTER TO command followed by START SLAVE on your MySQL or other Clustrix instance to start replication. All database access continues without restarting. There is absolutely no interruption in active connections during this process.

How is data distributed in Clustrix, and is there any user interaction required to ensure data is properly distributed and protected?

Clustrix automatically distributes data to ensure that data is written to and read with maximum efficiency. Data is evenly and redundantly spread across the cluster using a set of processes called the “rebalancer.” The rebalancer constantly runs in the background with low priority to ensure that nodes are evenly balanced and loaded, providing maximum performance and fault tolerance in the case of node or disk failure. The cluster will automatically reprotect around such failures without a need for user intervention.

How does Clustrix handle storage of binlogs for replication?

Clustrix doesn’t store binlogs in flat files like MySQL does. In Clustrix, binlogs are stored directly in the database and re-assembled in real time into readable formats as they are shipped off to other Clustrix or MySQL slaves.

It’s important to remember this when calculating disk space used in the Clustrix system. Particularly in high-transaction environments, Clustrix will store very large amounts of data in the binlogs, which will need to be trimmed regularly to keep disk space under control. Binlogs can be retrieved from the database for offline storage and archiving, just like you’re used to doing with MySQL.

How does Clustrix store logging information and provide space to store database dumps?

Each node in a Clustrix instance has a set of seven SSDs for data as well as one spinning-disk drive that is used for logging and temporary upload space. When uploading a file to Clustrix, it’s important to use the “/clustrix/” directory rather than “/”. The root “/” partition is only used to run the operating system, whereas the “/clustrix/” directory and “/var/log/” are mapped to the larger 500-600GB hard drive for scratch space, file uploads, and logging. This drive is independent from the database data, which is stored on the SSDs and accessed directly by the database.

We hope you found this information useful. If you want to learn more about how Clustrix can help your business seamlessly scale without limits, use the Chat feature on our homepage to talk to a representative.  If you would like to see other topics covered in our blog, please share them.