I have been working on some hybrid MariaDB setups lately and one of the more recent cool features that I have become familiar with is their GTID implementation. GTID – Global Transaction ID consists of a sequence of three numbers with the following format X – Y – Z.

X – Domain ID

• 32 bit unsigned integer
• Used to track multiple stream replication in a multi-master to slave setup
• Single master, or cluster master, setup all master nodes would have the same domain, default is 0

Y – Server ID

• 32 bit unsigned integer
• Unique for every server

Z – Sequence number

• 64 bit unsigned integer
• This is the sequence number for an event group written to the binlog thus keeping the nodes in sync

An example GTID implementation, and what I currently used in a hybrid setup deployment with a 3-Node Galera Cluster running on dedicated hardware replicating to multiple standalone MariaDB VM’s, consisted of the following:

• Cluster Node 1: 0 – 1 – Z
• Cluster Node 2: 0 – 2 – Z
• Cluster Node 3: 0 – 3 – Z
• Replication Node 1: 10 – 1 – Z
• Replication Node 2: 20 – 2 – Z

In this case, the Cluster is the master with Domain ID 0 and is replicating to a slave Node, Replication Node 1, and that slave is a Relay Master to the second replication Node, Replication Node 2.

The MariaDB implementation of GTID leads to some powerful capabilities when it comes to hybrid setups. Setups such as:

• Full replication between clusters
• Cluster to standalone replication and visa versa
• Primary transaction systems replicating to a single multi-master slave

My favorite being the ability to offload processing from a primary node, or set of nodes, to another node, or set off nodes, for things like backups, reporting, data warehousing, and other processes that have the possibility of impacting ongoing transactional load.

This isolates your primary setup to strictly handling the day to day transactional load with no impact. This is great from a performance perspective with the multi-master capability is made possible by GTID.