Seconds_Behind_Master 什么时候太大了？

Question

我的 mysql_slave 陷入了一个错误，并累积到 200,000+ Seconds_Behind_Master。我应该重建它并从头开始，还是让它自己赶上？

Answer 1

恕我直言

让它赶上。

该的Seconds_Behind_Master读书不是什么我靠，看是否赶上是可能的或值得的。不要害怕报告的数字。

您必须查看服务器的expire_logs_days设置。如果您的从站远远落后于二进制日志文件已被删除，那么您需要重新映像。

Answer 2

Seconds_Behind_Master真是一把双刃剑

当Seconds_Behind_Master显着增加时，关于 的输出有两种情况需要考虑SHOW SLAVE STATUS\G：

情景#1

如果Relay_Log_Space低于 1G，这表明 Slave 在通过 IO 线程读取其 Master 的 binlog 条目时出现问题。记录的时间戳是中继日志似乎是倾斜的，因为 Master 可能已经快速记录了它的 binlog，但是 Slave 的当前时间与其中继日志中的时间戳之间的差距增加了。寻找这样的事情：

• Master上的服务器负载
• 来自 Master 的长时间运行的查询
• 一系列 DML 语句，在 Master 上并行运行良好，然后在 Slave 上序列化
• Slave IO 线程上的网络延迟

场景#2

如果Relay_Log_Space启动超过2G，立即查看Slave_IO_Running和Slave_SQL_Running。很有可能，复制被破坏了。在大多数情况下，如果Replication中断，SQL Thread就死了，IO Thread保持运行（Slave_IO_Running是Yes，Slave_SQL_Running是No），因为IO Thread还在运行，它可以捕捉到Master发送到Slave中继的新SQL命令日志。那可以成长。如果任其发展，它可能会增长到填满磁盘的程度。如果您的警报方案只是检查是否Seconds_Behind_Master为 NULL，这应该会提示您快速解决 SQL 错误。如果Seconds_Behind_Master只是数字增加，这将由于一系列 DML 语句在 Master 上并行运行良好，然后在 Slave 上序列化（就像在场景 #1 中一样）而发生。本质上，来自 IO 线程的 SQL 语句的收集速度比 SQL 线程处理它们的速度要快。

结语

• 场景 #1 需要更多的故障排除和根本原因分析。
• 场景 #2 只是一个重写 Master 将其事务发送到 Slave 以一次处理 SQL 的指示。在这种情况下，您有三 (3) 个选择之一
  • 让复制迎头赶上
  • 关闭 Slave 上的 mysql，清除所有数据（mysql 文件夹除外）并重新加载 MySQL
  • 在SlaveRESET MASTER;上关闭mysql，在Master上，rsync /var/lib/mysql from Master to Slave，在Slave上启动mysql，设置复制
  • 使用 XtraBackup 执行 Master 的 Live Copy 并恢复到 Slave

这是我的帖子，可能有助于这些步骤

• MySQL 社区版：我可以一次性将我的整个服务器复制到另一台服务器上吗？（2011 年 10 月 14 日）
• XtraBackup 和 rsync 有什么区别？（2011 年 6 月 17 日）
• 如何将数据库从一台服务器移动到另一台服务器？（2011 年 5 月 23 日）
• 如果 Master 离线，您如何将 Master MySQL DB 与 Slave DB 更改重新同步？（2011 年 5 月 15 日）