mysql 5.6 gtid 复制从卡住（系统锁定）？

dba.stackexchange https://dba.stackexchange.com/questions/117068

  •  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. 。如果没有任何结果，您将不得不重新加载从属设备并从头开始设置复制。

许可以下： CC-BY-SA 和 归因
不隶属于 dba.stackexchange
scroll top