Galera Cluster propagates data over a cluster of servers using a synchronous multisource replication. All nodes in a cluster accept statements from the users, acting like a standalone MariaDB server. They reply to the user's queries and apply the requested data changes locally. Then, they propagate them to other nodes.

Nodes of Galera Cluster mostly behave like a normal MariaDB server, but they have several minor limitations. The users should be aware of what they can or cannot do with a MariaDB server, when it is part of Galera Cluster. The main limitation is that Galera only runs on Linux. Only the InnoDB storage engine is fully supported in Galera. An experimental support to MyISAM has been implemented, but its use is not recommended. A complete list of limitations can be found later in this chapter, in the Listing the limitations of Galera Cluster section.

There is no lower or upper limit to the number of nodes within a cluster. However, the cluster is guaranteed to be crash-safe only if there are at least three nodes.

Galera does not use loose consistency models such as the eventual consistency that is used by most MySQL products. Instead, it provides a high consistency level that is generally required for a DBMS. Even if the users can send SQL statements to any server, the writes are always applied in a given order. There is no sensible lag between nodes. On slow networks, a delay will be noticed, but it should only involve the commits. A query sent at a given time will always return the same result set, no matter which node it was addressed to. This is guaranteed thanks to synchronous replication.

Because of its nature, Galera can be used for several purposes. It can be used for load balancing, since all the nodes are constantly up to date. If nodes are geographically very distant, clients can even interact with the nearest node, reducing the latency. Galera also allows using one or more nodes as a backup that is always up to date, avoiding the loss of recent data that usually happens when restoring a normal backup. Or, it can simply be used as a traditional replication system, with all the clients querying only one master and considering other nodes as passive slaves.

Galera Cluster suits cloud computing well. The reason is a feature called automatic node provisioning, which makes scaling very easy.

All other MariaDB and MySQL replication solutions, including the built-in replication, are asynchronous. Asynchronous replication guarantees that all write operations that occur on a master are propagated to all its slaves. However, there is no guarantee about when it will happen. In fact, it is not uncommon on a busy environment that some slaves lag behind their master with a delay of hours, or even several days.

The characteristic of synchronous replication is that masters and slaves are synchronized. Transactions are processed at the same time and no delay should occur, in theory. As mentioned previously, synchronous replication has two important consequences: no data is lost after a master crash, and transactions are committed in the same order by all nodes.

However, implementing synchronous replication is a challenging quest for developers. Traditionally, this is done using distributed locks or two-phase commits. For example, SPIDER uses two-phase commits, as explained in Chapter 11, Data Sharding. Both these methods are much slower than asynchronous replication. Galera uses a different model, which is based on a transaction certification. A node, when it receives a SQL statement, executes it and propagates the write sets to the other nodes without waiting for a commit. The transaction is processed in parallel. Each node applies the writes without making them effective. If the modifications succeed, the node certificates the write set. When the first node receives a commit and all the nodes certify the write set, it makes the write sets effective and propagates the commit. Transactions are reordered before they are propagated. This diminishes the probabilities that they fail in some node (and thus in the whole cluster) because of a conflict. Statements that implicitly cause a commit are isolated from other write sets. This new model is the result of recent academic works on group communications and reordering technique. The following document describes the process in depth: http://infoscience.epfl.ch/record/32566/files/EPFL_TH2090.pdf.

While this is the model used by Galera, each node internally uses the traditional transactions provided by InnoDB. These mechanisms are executed autonomously by each server. For this reason, the replication implemented by Galera is sometimes called virtually synchronous replication.

Synchronous replication is made possible by wsrep, an API to implement this feature in MySQL and MariaDB. The wsrep API is a free acronym for the Write Set Replication API. Galera can be thought of as an implementation of this API, and as a plugin for MariaDB and MySQL. For this reason, it is sometimes called a wsrep provider. Other providers, independent from Galera, may come in the future.

The description of wsrep in the Launchpad project page says:

The repository of the wsrep project can be found at the following address: https://launchpad.net/wsrep.