MYSQL 备库延迟一直增加，无法设置READ_ONLY

最新推荐文章于 2024-09-12 18:12:10 发布

ant98002

最新推荐文章于 2024-09-12 18:12:10 发布

阅读量171

点赞数

文章标签：数据库 php

原文链接：http://www.cnblogs.com/o-to-s/articles/8319928.html

版权

本文详细记录了一次MySQL从库复制延迟的问题排查与解决过程，重点在于如何处理由mysqldump导出时产生的SET SESSION.SQL_LOG_BIN=0命令导致的复制异常。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

案例背景：

mysql 从库延迟一直增加，但RELAY_LOG_POS一直停止不前，设置READ_ONLY直接HANG死。用SHOW PROCESS LIST或者SHOW ENGINE INNODB STATUS均查看不到异常。

操作回顾：

1.接到业务需求方需要从另一个实例里迁移一张表过来并进行运算。

2. 导出表：

mysqldump -urebirth -p -h127.0.0.1  --complete-insert --extended-insert --single-transaction --default-character-set=utf8   --database db_name --tables table_name >table_name_0119.sql

3. 在目标库执行此文件：

source table_name_0119.sql

4. 对表做运算：

从库中断，原因：无TABLE_NAME此表。

分析：为何在主库上执行了导入命令，为何没有到从库呢，经过对BINLOG的分析，发现并没有产生TABLE_NAME相关的BINLOG.

检查导入数据文本：

在文件中发现了如下内容：

SET @@SESSION.SQL_LOG_BIN= 0;

明白是什么事了。

可为何会产生这个命令串呢

In MySQL 5.6 and later when mysqldump is used to create a backup and --set-gtid-purged is enabled (this is the default if GTIDs are enabled), then it also adds a

   SET @@SESSION.SQL_LOG_BIN= 0;

详细BUG连接：

https://bugs.mysql.com/bug.php?id=77845

在导出的时候SET-GTID-PURGED是默认开启的，所以生成了这个语句。知道此情况，那么就好解决了，在从库上执行不就完了。

5. 在从库上执行此文件：

source table_name_0119.sql

6. 重启复制：

stop slave;
start slave;

分析：

分析这些操作，并没有什么大的问题。可为何就造成复制一直延迟呢？

检查RELAY LOG：

mysqlbinlog --base64-output=decode-rows -v -v relbin3306.000008 > 0119.log
less 0119.log
找到对应的LOG POS位置， 发现此前做运行计算的SQL 就在这个POS位置。

解决方案：

拿出这个运行计算的SQL在从库手动跑一次，并跳过此操作：

STOP SLAVE;
SET GTID_NEXT="76dc568d-f4f1-11e7-96ab-00163e065098:322";
BEGIN; COMMIT;
SET GTID_NEXT="AUTOMATIC";
START SLAVE;

至此检查复制正常， set global read_only=1; 也能正常执行。

转载于:https://www.cnblogs.com/o-to-s/articles/8319928.html