5 min read

This article written by Pierre MAVRO, the author of MariaDB High Performance, provides a brief introduction to Galera Cluster.

(For more resources related to this topic, see here.)

Galera Cluster is a synchronous multimaster solution created by Codership. It’s a patch for MySQL and MariaDB with its own commands and configuration. On MariaDB, it has been officially promoted as the MariaDB Cluster.

Galera Cluster provides certification-based replication. This means that each node certifies the replicated write set against other write sets. You don’t have to worry about data integrity, as it manages it automatically and very well. Galera Cluster is a young product, but is ready for production.

If you have already heard of MySQL Cluster, don’t be confused; this is not the same thing at all. MySQL Cluster is a solution that has not been ported to MariaDB due to its complexity, code, and other reasons. MySQL Cluster provides availability and partitioning, while Galera Cluster provides consistency and availability. Galera Cluster is a simple yet powerful solution.

How Galera Cluster works

The following are some advantages of Galera Cluster:

  • True multimaster: It can read and write to any node at any time
  • Synchronous replication: There is no slave lag and no data is lost at node crash
  • Consistent data: All nodes have the same state (same data exists between nodes at a point in time)
  • Multithreaded slave: This enables better performance with any workload
  • No need of an HA Cluster for management: There are no master-slave failover operations (such as Pacemaker, PCR, and so on)
  • Hot standby: There is no downtime during failover
  • Transparent to applications: No specific drivers or application changes are required
  • No read and write splitting needed: There is no need to split the read and write requests
  • WAN: Galera Cluster supports WAN replication

Galera Cluster needs at least three nodes to work properly (because of the notion of quorum, election, and so on). You can also work with a two-node cluster, but you will need an arbiter (hence three nodes). The arbiter could be used on another machine available in the same LAN of your Galera Cluster, if possible.

The multimaster replication has been designed for InnoDB/XtraDB. It doesn’t mean you can’t perform a replication with other storage engines!

If you want to use other storage engines, you will be limited by the following:

  • They can only write on a single node at a time to maintain consistency.
  • Replication with other nodes may not be fully supported.
  • Conflict management won’t be supported.
  • Applications that connect to Galera will only be able to write on a single node (IP/DNS) at the same time.

As you can see in the preceding diagram, HTTP and App servers speak directly to their respective DBMS servers without wondering which node of the Galera Cluster they are targeting.

Usually, without Galera Cluster, you can use a cluster software such as Pacemaker/Corosync to get a VIP on a master node that can switch over in case a problem occurs. No need to get PCR in that case; a simple VIP with a custom script will be sufficient to check whether the server is in sync with others is enough.

Galera Cluster uses the following advanced mechanisms for replication:

  • Transaction reordering: Transactions are reordered before commitment to other nodes. This increases the number of successful transaction certification pass tests.
  • Write sets: This reduces the number of operations between nodes by writing sets in a single write set to avoid too much node coordination.
  • Database state machine: Read-only transactions are processed on the local node. Write transactions are executed locally on shadow copies and then broadcasted as a read set to the other nodes for certification and commit.
  • Group communication: High-level abstraction for communication between nodes to guarantee consistency (gcomm or spread).

To get consistency and similar IDs between nodes, Galera Cluster uses GTID, similar to MariaDB 10 replication. However, it doesn’t use the MariaDB GTID replication mechanism at all, as it has its own implementation for its own usage.

Galera Cluster limitations

Galera Cluster has limitations that prevent it from working correctly.

Do not go live in production if you haven’t checked that your application is in compliance with the limitations listed.

The following are the limitations:

  • Galera Cluster only fully supports InnoDB tables. TokuDB is planned but not yet available and MyISAM is partially supported.
  • Galera Cluster uses primary keys on all your tables (mandatory) to avoid different query execution orders between all your nodes. If you do not do it on your own, Galera will create one. The delete operation is not supported on the tables without primary keys.
  • Locking/unlocking tables and lock functions are not supported. They will be ignored if you try to use them.
  • Galera Cluster disables query cache.
  • XA transactions (global transactions) are not supported.
  • Query logs can’t be directed to a table, but can be directed to a file instead.
  • Other less common limitations exist (please refer to the full list if you want to get them all: http://galeracluster.com/documentation-webpages/limitations.html) but in most cases, you shouldn’t be annoyed with those ones.

Summary

This article introduced the benefits and drawbacks of Galera Cluster. It also discussed the features of Galera Cluster that makes it a good solution for write replications.

Resources for Article:

Further resources on this subject:

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here