MariaDB replication - slave lag due to gtid statements in relay log

Question

I'm doing a migration work from MySql to MariaDB where replication is involved, everything is working fine and compatibility of master MySql (5.5.59) to slave MariaDB (10.1.26) is good.

The problem occur when I enable the replication from MariaDB master to MariaDB slave (same versions: 10.1.26). In some situations, identified on massive updates, the slave start to lag. If I restore the master to MySql (5.5.59) and I replicate to the same slave in MariaDB, the lag never occur on the same set of updates.

I checked the relay logs in the MariaDB slave that is lagging, comparing the ones received when MySql is the master and the ones received when MariaDB is the master, the only differences are that when the master is MariaDB I can see statements related to gtid.

I would like to disable the presence of the gtid statements on the relay log when the master is MariaDB and make a replication similar to the "old style" MySql replication without gtid, but I've not found if is possible to do that.

Answer 1

The replication lag was due to the engine set in the table mysql.gtid_slave_pos in the slave server, by default this table is InnoDB and the tables that were receiving the replication updates are not InnoDB.

As explained in the link below, every transaction executed by the slave cause also an update on mysql.gtid_slave_pos, if the engines of the tables are different, that can cause a bad performance (in my case the server was lagging 4000+ seconds, changing the engine in the mysql.gtid_slave_pos the replication is now immediate).

https://mariadb.com/kb/en/library/mysqlgtid_slave_pos-table/

From MariaDB 10.3.1, a new parameter has been introduced to help with this problem: gtid_pos_auto_engines This parameter will create a different table mysql.gtid_slave_pos for each engine involved in the replication. Unfortunately seems not possible to accomplish that with previus version of MariaDB, the table mysql.gtid_slave_pos must be unique and the choice of its engine is up to the DBA and the tables/queries involved in the replication