mysql 5.6 gtid 复制从卡住(系统锁定)?
-
29-09-2020 - |
题
我已经设置了基于 5.6 gtid 的复制(在 5.6.26 上),当我这样做时它似乎可以工作,它复制了我在正常数据旁边创建的随机测试数据库。然而在某个时候一定发生了一些事情,因为我所看到的只是:
mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: System lock Master_Host: xxxxxxxxxxxxxxxxxx Master_User: xxxxxxxxxxxxxxxx Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysqld-bin.000141 Read_Master_Log_Pos: 169293671 Relay_Log_File: mysqld-relay-bin.000003 Relay_Log_Pos: 16861206 Relay_Master_Log_File: mysqld-bin.000141 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 16860994 Relay_Log_Space: 169298584 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 55203 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 Master_UUID: 7846a847-62c7-11e5-91a6-e06995de432e Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: System lock Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085 Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274 Auto_Position: 1
现在最初的“Slave_SQL_Running_State”表示“从中继日志读取事件”或类似的内容,它现在也更改为系统锁定(IO状态总是这么说)。
看来 Seconds_Behind_Master
正在稳步增长,并且中继日志在文件系统上的大小快速增长,而 Executed_gtid_set
似乎确实发生了变化,但似乎仍然有些不对劲,因为它落后了太多......
这是进程列表:
mysql> show processlist; +------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+ | 1877 | root | localhost | NULL | Sleep | 6076 | | NULL | | 1878 | root | localhost | NULL | Query | 0 | init | show processlist | | 1886 | system user | | NULL | Connect | 783 | System lock | NULL | | 1887 | system user | | NULL | Connect | 0 | System lock | NULL | | 1888 | system user | | NULL | Connect | 783 | Waiting for an event from Coordinator | NULL | | 1889 | system user | | NULL | Connect | 55455 | System lock | NULL | +------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
我试图停止奴隶并再次启动它,但没有帮助。
有人知道我可以尝试让这项工作再次发挥作用吗?将不胜感激。
谢谢
解决方案
因为我看到超过2个 system user
进程列表中的条目,我假设您正在使用多线程复制(从并行工作者 > 1).
这看起来像一个错误
2014 年 10 月 29 日, David Moss
感谢您的反馈意见。此问题已在错误 17326020 中解决,并且以下内容已添加到 MySQL 5.6.21 和 5.7.5 变更日志中:
当I/O线程在交易中间使用GTID和多线从分子重新连接到主人时,它未能中止交易,在中继日志中留下部分事务,然后再次检索相同的事务。当执行继电器日志的旋转时,会发生这种情况。现在,在重新连接时,服务器在此类情况下旋转日志之前先检查,并首先等待任何正在进行的交易完成。
因此,不会添加任何新内容来覆盖此错误,并且我将其作为修复关闭。
2014 年 12 月 10 日,这一表述为: Laurynas Biveinis
问题:
使用MT,GTID和自动定位启用,当工人通过IO线程重新连接在RelayLog上保留的部分事务时,它将等待XID日志事件提交交易。
不幸的是,SQL线程协调器将在下一个RelayLog文件上达到主旋转事件,并将等待所有工人在应用旋转之前完成任务。
分析:
当重新连接后的IO线程再次检索整个事务时,一旦注意到此旋转从主体旋转,就必须回滚部分事务。
该错误报告了错误#17326020已解决的同一问题,并且报告的问题不再可再现了。因此,此补丁只是添加了一个新的测试用例。
建议
跑步 FLUSH BINARY LOGS;
在师父上
查看移动是否触发 SQL 线程的响应。
如果没有,请继续删除 从并行工作者 从 my.cnf
并重新启动mysql。
自从你启动 MySQL 并设置主从服务器后, error 1236
, ,这意味着您正在尝试从不可能的位置建立复制。在您收到的 GTID 和错误消息的上下文中,完全识别 GTID 集中的一组查询所需的二进制日志不再存在,
回头看看你的 SHOW SLAVE STATUS\G
Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274
由此看来,最后执行的GTID是 7846a847-62c7-11e5-91a6-e06995de432e:4783274
这意味着二进制日志已经或曾经 7846a847-62c7-11e5-91a6-e06995de432e:4783275
不复存在。
如果您停止从属设备上的复制,将复制关闭足够长的时间,以便主设备轮换从属设备仍需要查看的二进制日志(通过 expire_logs_days),然后打开复制,我可以看到这种情况发生。
在您的特定情况下,尝试对二进制日志进行 mysqlbinlog 转储 mysqld-bin.000141
. 。如果没有任何结果,您将不得不重新加载从属设备并从头开始设置复制。