Binary Log基于ROW模式下的从库复制延时问题

关键字

innodb version 5.7 replication delay

参考&引用

• MySQL Docs: slave_rows_search_algorithms
• slave-performance-too-slow-with-row-based-events-causes-and-workarounds

问题描述

业务表没有主键(唯一键), 主库执行了一条大量删除的DELETE语句导致，导致Slave延时。

表结构设计

由于binlog 是基于Row模式的，主库的一条大量删除DELETE语句会产生大量binlog日志。这种情况下,从库 SQL Thread 在重放Relay Log时，由于表结构不存在唯一键（没有好的索引），导致所有重放都是一次全表扫描。

从设计上讲，所有表都应该有唯一主键，至少有自增主键（最好强制要求所有表均有自增主键）。这次的问题主要是项目引用的开源的项目（XXX）, 表结构设计的非常有问题。

问题解决

表结构补上唯一索引（或加上自增主键）是最好的方式。 但是如果因为一些原因，无法改表结构的情况，可以临时通过调整slave_rows_search_algorithms参数为INDEX_SCAN,HASH_SCAN(默认值INDEX_SCAN,TABLE_SCAN)，改变从库复制表搜索算法，来加速复制。

--动态参数
set global slave_rows_search_algorithms = 'INDEX_SCAN,HASH_SCAN';

官方文档说明：

* The default value is INDEX_SCAN,TABLE_SCAN, which means that all searches that can use indexes do use them, and searches without any indexes use table scans.

* To use hashing for any searches that do not use a primary or unique key, set INDEX_SCAN,HASH_SCAN. Specifying INDEX_SCAN,HASH_SCAN has the same effect as specifying INDEX_SCAN,TABLE_SCAN,HASH_SCAN, which is allowed.

对照测试实验

同一从库上堆积一个大事务情况下,相同的Exec_Master_Log_Pos,相同时间内,先后观察innodb undo 数相差10倍+（数值仅参考）。

INDEX_SCAN,TABLE_SCAN INDEX_SCAN,HASH_SCAN