☰

MySQL 复制从属中的 Seconds_behind_master 值不断增加

tag-icon • tag-icon mysql-replication
MySQL 复制从属中的 Seconds_behind_master 值不断增加

我们有一个MySQL 5.0.77主从复制。过去几周，复制运行不正常，并且出现Duplicate entry error 1062。该Set Global Skip-counter选项没有帮助，所以我不得不error no.1062通过将其添加到/etc/my.cnf文件中来跳过 ，然后它报告了一个特定数据库中的表不存在错误。

上周末，我取出了mysqldump该数据库，并在 Slave 中恢复。然后，Slave IO_Thread和Slave_SQL都开始正常运行，看起来复制又回到了正轨。该Seconds_behind_master值非常高，然后在过去 4 天内开始减少。

今天检查slave的复制状态，发现seconds_behind_master从早上开始这个值就一直在增加，我停了一次slave IO_Thread，然后seconds_behind_master就变成Null了，然后我启动之后，这个IO_thread值就和原来一样了，并且一直在增加。

我看到一个进程从早上开始运行 system user gss-app Connect 9535736 copy to tmp table ALTER TABLEqueue_clicks ADD INDEX(puid)

请帮我解决这个问题。谢谢。

#mysql> show slave status\G;
`*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 203.x.x.x
                Master_User: replication
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000990
        Read_Master_Log_Pos: 185674180
             Relay_Log_File: mysqld-relay-bin.000224
              Relay_Log_Pos: 9286354
      Relay_Master_Log_File: mysql-bin.000774
           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: 472142385
            Relay_Log_Space: 112995681998
            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: 9533355
1 row in set (0.00 sec)`

答案1

如果 IO 和 SQL 正在运行，并且正在Relay_Master_Log_File赶上，我不会担心它Master_Log_File。我相信延迟是因为您的总中继日志文件很大，大约 105G -Relay_Log_Space: 112995681998并且考虑到从属位于 000774 位置，主位于 000990 位置，共有 214 个二进制日志，每个大约 468M（105G/214）等待在从属上重播。

我的建议是密切关注Relay_Master_Log_File并确保它正在运行并赶上Master_Log_File。我还看到主主机位于公共 IP 地址中，此复制是通过公共网络还是慢速 WAN 进行的？这可能会引起延迟，链接越快越好。

答案2

当您停止 IO_Thread 并且 SQL_Thread 赶上可用的中继日志数据时，Seconds_Behind_Master 将变为 NULL，因此在这种情况下无法反映正确的延迟。您可以在不同情况下找到正确的方式来解释 Seconds_Behind_Master 的值：https://scalegrid.io/blog/mysql-tutorial-understanding-the-seconds-behind-master-value/

答案3

我以前也遇到过完全相同的问题。

请进行以下更改，以纠正从属启动后“Seconds_Behind_Master”增加的问题。

首先检查从服务器上的“trx”值

  • 显示类似‘%trx%’的变量；

如果“innodb_flush_log_at_trx_commit”的值为“1”，如下所示

  • 变量名称 | 值 |

  • innodb_api_trx_level | 0 |

  • 默认情况下，innodb_flush_log_at_trx_commit 设置为 1。

  • innodb_use_global_flush_log_at_trx_commit | 开启 |

然后将此值更改为“2”

  • 设置全局innodb_flush_log_trx_commit = 2;

一旦您在 mysql 客户端中更改了这一点，也请在 my.cnf 文件中更改这一点，以确保一旦 mysql 重新启动，该值仍然存在。

  • 修改 /etc/mysql/my.cnf

搜索“innodb_flush_log_at_trx_commit=1”

并将其值也改为“2”。

这将解决您的“Seconds_Behind_Master”问题。

相关内容