and MariaDB Galera Cluster can be used together. However, there are some things that have to be taken into account.
If you want to use and MariaDB Galera Cluster together, then the following tutorials may be useful:
Configuring a Cluster Node as a Replication Master
If a Galera Cluster node is also a , then some additional configuration may be needed.
Like with , write sets that are received by a node with are not written to the by default.
If the node is a replication master, then its replication slaves only replicate transactions that are in the binary log, so this means that the transactions that correspond to Galera Cluster write-sets would not be replicated by any replication slaves by default. If you would like a node to write its replicated write sets to the , then you will have to set . If the node has any replication slaves, then this would also allow those slaves to replicate the transactions that corresponded to those write sets.
See for more information.
Configuring a Cluster Node as a Replication Slave
If a Galera Cluster node is also a , then some additional configuration may be needed.
If the node is a replication slave, then the node's will be applying transactions that it replicates from its replication master. Transactions applied by the slave SQL thread will only generate Galera Cluster write-sets if the node has set. Therefore, in order to replicate these transactions to the rest of the nodes in the cluster, must be set.
If the node is a replication slave, then it is probably also a good idea to enable . When this is enabled, the node will restart its whenever it rejoins the cluster.
Parallel Replication Support
Historically, Galera Cluster nodes acting as asynchronous replication slaves were restricted to single-threaded execution (slave_parallel_threads=0). Enabling parallel replication often resulted in deadlocks due to conflicts between ordering and Galera's internal pre-commit ordering.
As of MariaDB 12.1.1, this limitation has been resolved.
On supported versions, you can safely configure slave_parallel_threads to a value greater than 0 to improve the performance of incoming replication streams.
Recommended Configuration (MariaDB 12.1.1+):
Replication Filters
Both and support , so extra caution must be taken when using all of these features together. See 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 to the same value on each node in a given cluster. Since uses a , 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 . The of each cluster node might even contain roughly the same transactions and if is set and if 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 value on each node in a given cluster. For example, if is set and if another cluster or a standard MariaDB Server is using to replicate transactions from each cluster node individually, then it would be required to set a different 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 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 to the server IDs of all nodes in the same cluster when executing . For example, this might be required when circular replication is set up between two separate clusters, and each cluster node has a different value, and each cluster has set.
This page is licensed: CC BY-SA / Gnu FDL