> For the complete documentation index, see [llms.txt](https://mariadb.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mariadb.com/docs/galera-cluster/high-availability/using-mariadb-replication-with-mariadb-galera-cluster/using-mariadb-replication-with-mariadb-galera-cluster-using-mariadb-replica.md).

# Using MariaDB Replication with MariaDB Galera Cluster

[MariaDB replication](/docs/server/ha-and-performance/standard-replication.md) and [MariaDB Galera Cluster](/docs/galera-cluster/readme.md) can be used together. However, there are some things that have to be taken into account.

## Tutorials

If you want to use [MariaDB replication](/docs/server/ha-and-performance/standard-replication.md) and [MariaDB Galera Cluster](/docs/galera-cluster/readme.md) together, then the following tutorials may be useful:

* [Configuring MariaDB Replication between MariaDB Galera Cluster and MariaDB Server](/docs/galera-cluster/high-availability/using-mariadb-replication-with-mariadb-galera-cluster/configuring-mariadb-replication-between-mariadb-galera-cluster-and-mariadb.md)
* [Configuring MariaDB Replication between Two MariaDB Galera Clusters](/docs/galera-cluster/high-availability/using-mariadb-replication-with-mariadb-galera-cluster/configuring-mariadb-replication-between-two-mariadb-galera-clusters.md)

## Configuring a Cluster Node as a Replication Primary

If a Galera Cluster node is also a [replication primary](/docs/server/ha-and-performance/standard-replication/replication-overview.md), then some additional configuration may be needed.

Like with [MariaDB replication](/docs/server/ha-and-performance/standard-replication.md), write sets that are received by a node with [Galera Cluster's certification-based replication](/docs/galera-cluster/readme/about-galera-replication.md) are not written to the [binary log](/docs/server/server-management/server-monitoring-logs/binary-log.md) by default.

If the node is a replication primary, then its replicas 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 replicas by default. If you would like a node to write its replicated write sets to the [binary log](/docs/server/server-management/server-monitoring-logs/binary-log.md), then you will have to set [log\_slave\_updates=ON](/docs/server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables.md#log_slave_updates). If the node has any replicas, then this would also allow those replicas to replicate the transactions that corresponded to those write sets.

See [Configuring MariaDB Galera Cluster: Writing Replicated Write Sets to the Binary Log](/docs/galera-cluster/galera-management/configuration/configuring-mariadb-galera-cluster.md#writing-replicated-write-sets-to-the-binary-log) for more information.

## Configuring a Cluster Node as a Replication Replica

If a Galera Cluster node is also a [replication replica](/docs/server/ha-and-performance/standard-replication/replication-overview.md), then some additional configuration may be needed.

If the node is a replication replica, then the node's [replica SQL thread](/docs/server/ha-and-performance/standard-replication/replication-threads.md#slave-sql-thread) will be applying transactions that it replicates from its replication primary. Transactions applied by the replica SQL thread will only generate Galera Cluster write-sets if the node has [log\_slave\_updates=ON](/docs/server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables.md#log_slave_updates) set. Therefore, in order to replicate these transactions to the rest of the nodes in the cluster, [log\_slave\_updates=ON](/docs/server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables.md#log_slave_updates) must be set.

If the node is a replication replica, then it is probably also a good idea to enable [wsrep\_restart\_slave](/docs/galera-cluster/reference/galera-cluster-system-variables.md#wsrep_restart_slave). When this is enabled, the node will restart its [replica threads](/docs/server/ha-and-performance/standard-replication/replication-threads.md#threads-on-the-slave) whenever it rejoins the cluster.

## Parallel Replication Support

Historically, Galera Cluster nodes acting as asynchronous replication replicas were restricted to single-threaded execution (`slave_parallel_threads=0`). Enabling parallel replication often resulted in deadlocks due to conflicts between [Binary Log Group Commit (BGC)](/docs/server/server-usage/storage-engines/innodb/binary-log-group-commit-and-innodb-flushing-performance.md) ordering and Galera's internal pre-commit ordering.

As of MariaDB 12.1.1, this limitation has been resolved.

{% hint style="info" %}
This fix is available in MariaDB 12.1.1 and later.
{% endhint %}

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+):

```sql
SET GLOBAL slave_parallel_threads = 4; -- Adjust based on workload
SET GLOBAL slave_parallel_mode = 'optimistic';
```

## Replication Filters

Both [MariaDB replication](/docs/server/ha-and-performance/standard-replication.md) and [MariaDB Galera Cluster](/docs/galera-cluster/readme.md) support [replication filters](/docs/server/ha-and-performance/standard-replication/replication-filters.md), so extra caution must be taken when using all of these features together. See [Configuring MariaDB Galera Cluster: Replication Filters](/docs/galera-cluster/galera-management/configuration/configuring-mariadb-galera-cluster.md#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](/docs/server/ha-and-performance/standard-replication/gtid.md#server_id) to the same value on each node in a given cluster. Since [MariaDB Galera Cluster](/docs/galera-cluster/readme.md) uses a [virtually synchronous certification-based replication](/docs/galera-cluster/readme/about-galera-replication.md), 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](/docs/server/ha-and-performance/standard-replication.md). The [binary logs](/docs/server/server-management/server-monitoring-logs/binary-log.md) of each cluster node might even contain roughly the same transactions and [GTIDs](/docs/server/ha-and-performance/standard-replication/gtid.md) if [log\_slave\_updates=ON](/docs/server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables.md#log_slave_updates) is set and if [wsrep GTID mode](/docs/galera-cluster/high-availability/using-mariadb-replication-with-mariadb-galera-cluster/using-mariadb-gtids-with-mariadb-galera-cluster.md#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](/docs/server/ha-and-performance/standard-replication/gtid.md#server_id) value on each node in a given cluster. For example, if [log\_slave\_updates=OFF](/docs/server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables.md#log_slave_updates) is set and if another cluster or a standard MariaDB Server is using [multi-source replication](/docs/server/ha-and-performance/standard-replication/multi-source-replication.md) to replicate transactions from each cluster node individually, then it would be required to set a different [server\_id](/docs/server/ha-and-performance/standard-replication/gtid.md#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](/docs/server/ha-and-performance/standard-replication/gtid.md#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](/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to.md#ignore_server_ids) to the server IDs of all nodes in the same cluster when executing [CHANGE MASTER TO](/docs/server/reference/sql-statements/administrative-sql-statements/replication-statements/change-master-to.md). For example, this might be required when circular replication is set up between two separate clusters, and each cluster node has a different [server\_id](/docs/server/ha-and-performance/standard-replication/gtid.md#server_id) value, and each cluster has [log\_slave\_updates=ON](/docs/server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables.md#log_slave_updates) set.

<sub>*This page is licensed: CC BY-SA / Gnu FDL*</sub>

{% @marketo/form formId="4316" %}