MariaDB Replication

MariaDB replication works like MySQL's — binary log events shipped to replicas and applied through a relay log — with a different GTID model and different syntax.

GTID model

A MariaDB GTID is domain_id-server_id-sequence.

The domain is the distinguishing feature: it identifies an independent stream of transactions. Separate domains can be replicated in parallel and merged from multiple sources without conflict, which is what makes MariaDB's multi-source replication straightforward.

SELECT @@gtid_current_pos;    -- what this server has applied
SELECT @@gtid_binlog_pos;
SELECT @@gtid_slave_pos;

Setting up a replica

-- On the primary.
CREATE USER 'repl'@'10.20.1.%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.20.1.%';
 
-- On the replica.
SET GLOBAL gtid_slave_pos = '1-1-12345';   -- from the backup metadata
CHANGE MASTER TO
  MASTER_HOST = 'primary.internal',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'password',
  MASTER_USE_GTID = slave_pos,
  MASTER_SSL = 1;
START SLAVE;
SHOW SLAVE STATUS\G

Take the initial copy with mariabackup (physical, fast) or mariadb-dump --master-data=2 --single-transaction (logical), both of which record the position to resume from.

Parallel apply

slave_parallel_threads = 8
slave_parallel_mode = conservative     # optimistic allows more parallelism, with rollbacks
slave_domain_parallel_threads = 4

optimistic mode applies transactions in parallel speculatively and rolls back on conflict. It can be substantially faster on workloads with few conflicts, and slower on conflict-heavy ones — measure with your own workload.

Semi-synchronous replication

rpl_semi_sync_master_enabled = ON
rpl_semi_sync_master_timeout = 1000
rpl_semi_sync_slave_enabled = ON

As in MySQL, this narrows the data-loss window rather than eliminating it, and it silently falls back to asynchronous on timeout. Monitor Rpl_semi_sync_master_status.

Multi-source replication

MariaDB replicates from several primaries into one replica using named connections:

CHANGE MASTER 'shard_a' TO MASTER_HOST='a.internal', MASTER_USE_GTID=slave_pos;
CHANGE MASTER 'shard_b' TO MASTER_HOST='b.internal', MASTER_USE_GTID=slave_pos;
START ALL SLAVES;
SHOW ALL SLAVES STATUS\G

Useful for consolidating shards into one reporting instance. Give each source a distinct gtid_domain_id so the streams stay independent.

Monitoring

Watch Slave_IO_Running, Slave_SQL_Running, Seconds_Behind_Master and Last_Error, with the same caveat as MySQL: Seconds_Behind_Master reads zero when the IO thread has stopped. Compare gtid_slave_pos against the primary's gtid_binlog_pos for a reliable measure, and set read_only = ON on replicas to prevent accidental local writes.