Using MariaDB Replication with MariaDB Galera Cluster
Contents
MariaDB replication and MariaDB Galera Cluster can be used together. However, there are some things that have to be taken into account.
Tutorials
If you want to use MariaDB replication and MariaDB Galera Cluster together, then the following tutorials may be useful:
- Configuring MariaDB Replication between MariaDB Galera Cluster and MariaDB Server
- Configuring MariaDB Replication between Two MariaDB Galera Clusters
Configuring a Cluster Node as a Replication Master
Like with MariaDB replication, write sets that are received by a node with Galera Cluster's certification-based replication are not written to the binary log by default. If you would like a node to write its replicated write sets to the binary log, then you will have to set log_slave_updates=ON
. If the node has any slaves, then this would also allow those slaves to replicate the transactions that corresponded to those write sets. See Configuring MariaDB Galera Cluster: Writing Replicated Write Sets to the Binary Log.
Configuring a Cluster Node as a Replication Slave
If a Galera Cluster node is also a replication slave, then that node's slave SQL thread will be applying transactions that it replicates from its replication master. If the node has log_slave_updates=ON
set, then each transaction that the slave SQL thread applies will also generate a Galera Cluster write set that is replicated to the rest of the nodes in the cluster.
In this case, it is probably also a good idea to enable wsrep_restart_slave
, so that the node will restart its slave threads whenever it rejoins its cluster.
Replication Filters
Both MariaDB replication and MariaDB Galera Cluster support replication filters, so extra caution must be taken when using all of these features together. See Configuring MariaDB Galera Cluster: Replication Filters for more details on how MariaDB Galera Cluster interprets replication filters.
Setting server_id on Cluster Nodes
Setting the Same server_id on Each Cluster Node
It is most common to set server_id
to the same value on each node in a given cluster. Since MariaDB Galera Cluster uses a virtually synchronous certification-based replication, all nodes should have the same data, so in a logical sense, a cluster can be considered in many cases a single logical server for purposes related to MariaDB replication. The binary logs of each cluster node might even contain roughly the same transactions and GTIDs if log_slave_updates=ON
is set and if wsrep GTID mode is enabled and if non-Galera transactions are not being executed on any nodes.
Setting a Different server_id on Each Cluster Node
There are cases when it might make sense to set a different server_id
value on each node in a given cluster. For example, if log_slave_updates=OFF
is set and if another cluster or a standard MariaDB Server is using multi-source replication to replicate transactions from each cluster node individually, then it would be required to set a different server_id
value on each node for this to work.
Keep in mind that if replication is set up in a scenario where each cluster node has a different server_id
value, and if the replication topology is set up in such a way that a cluster node can replicate the same transactions through Galera and through MariaDB replication, then you may need to configure the cluster node to ignore these transactions when setting up MariaDB replication. You can do so by setting IGNORE_SERVER_IDS
to the server IDs of all nodes in the same cluster when executing CHANGE MASTER TO
. For example, this might be required when circular replication is set up between two separate clusters, and each cluster node as a different server_id
value, and each cluster has log_slave_updates=ON
set.