MariaDB主从复制延迟：GTID中继日志引发同版本批量更新异常

我之前也碰到过类似的主从复制性能差异问题，结合你描述的场景——MySQL 5.5.59主库→MariaDB 10.1.26从库复制完全正常，但同版本MariaDB 10.1.26主从在批量更新场景下就出现从库延迟，换回MySQL主库后延迟立刻消失，核心差异应该出在MariaDB主库的binlog生成逻辑、复制相关参数或者事务处理机制上，下面给你几个具体的排查和解决方向：

• 检查Binlog格式配置差异
  MySQL 5.5默认可能采用STATEMENT格式的binlog，而MariaDB 10.1虽然兼容该格式，但在批量更新场景下，不同格式的binlog会导致从库执行效率天差地别。比如如果MariaDB主库用了ROW格式，从库的行搜索算法如果没优化，就容易变慢。先对比两者的binlog格式：

  SHOW VARIABLES LIKE 'binlog_format';
  

  如果MySQL主库用的是STATEMENT，而MariaDB主库用的是ROW或MIXED，可以临时把MariaDB主库的binlog_format改成STATEMENT，测试批量更新时的从库延迟情况，看是否能缓解。

• 调整MariaDB主库的组提交参数
  MariaDB 10.1引入了一些binlog组提交的优化参数，比如binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count，这些参数是为了提升主库的吞吐量，但会让binlog写入有一定延迟，间接导致从库同步慢。检查这些参数的设置：

  SHOW VARIABLES LIKE 'binlog_group_commit%';
  

  如果主库开启了延迟组提交（binlog_group_commit_sync_delay不为0），可以临时设置为0关闭延迟，再测试批量更新场景的延迟情况。

• 开启从库的并行复制
  虽然MySQL主到MariaDB从没问题，但同版本MariaDB主从之间，主库生成的binlog可能更适合并行处理。MariaDB 10.1支持并行复制，可以调整从库的并行工作线程数来提升批量更新的处理速度：

  SET GLOBAL slave_parallel_workers = 4; -- 数值可以根据服务器CPU核心数调整，比如CPU核心的一半
  

  另外，还可以检查从库的磁盘IO相关参数，比如innodb_flush_log_at_trx_commit和sync_binlog，如果是性能优先的场景，可以适当放宽这些参数（比如innodb_flush_log_at_trx_commit=2，sync_binlog=100），减少磁盘IO等待时间。

• 对比两种主库生成的Binlog内容
  直接抓取MySQL主库和MariaDB主库在执行相同批量更新时生成的binlog，对比两者的差异，就能找到问题根源。用mysqlbinlog工具解析：

  mysqlbinlog --base64-output=decode-rows -v mysql-bin.000001 > mysql_binlog.txt
  mysqlbinlog --base64-output=decode-rows -v mariadb-bin.000001 > mariadb_binlog.txt
  

  查看MariaDB生成的binlog是否有更多的行变更记录，或者语句执行逻辑的差异——比如是否MariaDB把批量更新拆分成了更多小事务，导致从库需要执行更多操作。

• 排查主库的事务锁等待情况
  MariaDB 10.1相对于MySQL 5.5，在InnoDB引擎的锁机制上有一些优化，但也可能在批量更新时产生不同的锁等待行为，导致主库的binlog写入延迟，进而传递到从库。在主库执行批量更新时，用下面的命令查看锁等待状态：

  SHOW ENGINE INNODB STATUS;
  

  对比MySQL主库的锁等待情况，看MariaDB主库是否有异常的锁占用，导致事务提交变慢。

内容的提问来源于stack exchange，提问作者Jacopo