At Percona Managed Services, we manage Percona Server for MySQL, Community MySQL, and MariaDB. There are slight differences when configuring and managing MariaDB GTID replication. In this blog, we’ll show you how to convert MariaDB binary log file and position-based replication to GTID replication.

In my lab, we have two test nodes; both servers will have Debian 11 and MariaDB10.5.19 with mariabackup installed.

The PRIMARY server is deb11m8m (IP: 192.168.56.190), and the REPLICA server name is deb11m8s (IP: 192.168.56.191).

1. Install MariaDB on Debian 11 on PRIMARY and REPLICA

1.1 Reset root user password and create a replication user

1.2 Configure my.cnf on PRIMARY and REPLICA

PRIMARY

2. Let’s set up binary log and position-based replication between PRIMARY and REPLICA with the stream copy method.

2.1 on REPLICA

2.2 on PRIMARY

2.3 On REPLICA, get binlog information

2.4 On REPLICA, prepare the backup

2.5 Set up the replication 

We have now set up binary log and position-based replication between the PRIMARY and REPLICA servers. Our next step is to convert this replication to GTID-based replication.

MariaDB and MySQL have different GTID implementations.

MariaDB GTID consists of three numbers separated with dashes ‘-‘. For example:

0-1-10: The first number, 0, is the domain ID, the second number is the server ID, and the third number is the sequence number.

MySQL GTID has two parts, source_id  and transaction_id, separated by a colon character (:) .

e.g., 3E11FA47-71CA-11E1-9E33-C80AA9429562:23

The source_id  is the source server’s server_uuid, and the transaction_id is the transaction sequence number committed on the source.

Let’s continue.

On PRIMARY, we enable GTID by running the below command.

ON REPLICA

On REPLICA, we need to stop replication and extract the values of Relay_Master_Log_File and Exec_Master_Log_Pos from the output.

In our case, the Relay_Master_Log_File value is bin_log.000002, and the Exec_Master_Log_Pos is 1206.

On PRIMARY, we could use the below query to get the GTID position that corresponds to these binary log coordinates on PRIMARY.

We can now modify the replica configuration on the REPLICA server deb11m8s by executing the following statements:

The SHOW SLAVE STATUS output Using_Gtid: Slave_Pos and Gtid_IO_Pos: 1-1-2,0-1-4 indicates that the slave uses GTIDs to track replication. We could use the above command to set up GTID replication on other replicas as well.

When running CHANGE MASTER TO master_use_gtid=slave_pos; and setting the MASTER_USE_GTID replication parameter, you have the option of enabling Global Transaction IDs to use either the current_pos or slave_pos values.

Using the value current_pos causes the replica to set its position based on the gtid_current_pos system variable, which is a union of gtid_binlog_pos and gtid_slave_pos. Using the value slave_pos causes the replica to instead set its position based on the gtid_slave_pos system variable. You may run into issues when you use the value current_pos if you write any local transactions on the replica. For details, please refer to https://mariadb.com/kb/en/gtid/.

On Community MySQL or Percona Server for MySQL, the parameter to enable GTID replication is
gtid-mode=ON enforce-gtid-consistency.

The command is:

Conclusion

We can see that the procedure to enable GTIDs on MariaDB replication is simple, but the commands and parameters are a bit different.

As mentioned, Percona offers Support and Managed Services for Community versions of MariaDB. At the same time, we encourage MariaDB users to explore Percona Server for MySQL as an alternative. Should you make the decision to migrate to Percona Software for MySQL, our experts will assist throughout the migration process and support you after the migration is complete.

 

Contact us to discuss migration options

 

Hope this is helpful for your daily MySQL and MariaDB management.

Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments