点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！

告警为主从复制异常，登录从库发现从库正常运行，判断可能为主从复制进程异常，通过以下命令判断：

SHOW SLAVE STATUS

目前监控通过此命令中Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master来获取数据判断从库状态以及复制延迟时间；

• Slave_IO_Running(从库的 I/O 线程运行状态)
• Slave_SQL_Running(从库的 SQL 线程运行状态)
• Last_Errno(最后错误码)
• Last_Error(最后复制错误信息)
• Seconds_Behind_Master(从库与主库延迟时间)

通过此命令发现主从复制进程出现问题，检查发现从库Slave_IO_Running，Slave_SQL_Running值已为No， 查看错误码为1197，报错信息为：

Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage; increase this MySQLd variable and try again;

MAX_BINLOG_CACHE_SIZE参数表示binlog能够使用最大cache内存大小。

SHOW VARIABLES LIKE ‘MAX_BINLOG_CACHE_SIZE’

报错说明参数MAX_BINLOG_CACHE_SIZE设置过小，查询MAX_BINLOG_CACHE_SIZE发现其设置值为2G左右，针对一般场景其分配是足够的，说明库应该存在正在执行的大事务；

performance_schema.replication_applier_status_by_worker用于提供MySQL复制中每个复制线程的信息，这些线程负责将master的binlog应用到slave上。

SELECT * FROM performance_schema.replication_applier_status_by_worker

查询发现报错因为一个表正在执行删除事务引起，定位到出现的问题，因为库目前正在执行大表清理，报错表涉及大表清理任务，所以推测应为批量删除数据量过大导致；

表清理设定为小粒度清理，且其它大表清理时未出现报错情况，初步可能为该表涉及大字段导致。

No.1

SELECT count(*) FROM your_database.your_table_name

查询表面该表行数据量并不算大，分析其字段结构情况；

DESC your_database.your_table_name

通过表结构发现其有字段类型为longtext的大字段结构，一般MySQL不推荐使用TEXT字段类型,其不但消耗大量的网络和IO带宽，同时在该表上的DML操作都会变得很慢；

SELECT table_name,avg_row_length,

concat(round()) as “”,
concat(round()) as “”
FROM information_schema.tables
WHERE table_schema = “your_database”
ORDER BY avg_row_length desc
limit 20;

进一步查询可以发现该表行数据长度较大：

方法1：

将MAX_BINLOG_CACHE_SIZE参数值调大后重启主从复制进程后执行大表清理事务，注意此环境为双主架构，需要将两个节点MySQL参数同时调整并重启进程生效，只有一个节点调整会导致SQL同步线程报错。

方法2：

将本次循环delete清理数据粒度继续缩小，比如将一次清理一万行数据改为一千行，数据清理时间随之会增长。

大表清理时，首先避免使用DELETE进行直接全表清理的情况，而是采用循环detele小粒度清理方式；

按规则一次清理定量数据，而一次清理定量数据的标准，不仅仅参考大表的行数据量，也要注意其是否涉及大字段；

同时加强审计，对开发提交SQL中使用TEXT字段类型严格评审，尽量避免使用此字段类型，且执行清理应避开业务使用高峰期，上述任务执行时在周末非业务使用时间段，所以并无对业务使用产生影响。

END