MySQL 复制停止超过 10 天，expire_logs_days=10 时复制是否可以正常工作？

Question

我对复制的工作原理一无所知。这是我的场景。

今天（4 月 6 日）我意识到我们的复制从站在 3 月 20 日出现了一个失败的“CREATE USER”命令导致的错误。此后，没有发生复制。

这会留下六天左右的时间间隔，expire_logs_days主服务器上的日志会过期，而从服务器不会进行复制。

我能够跳过错误并再次进行复制。这一切都赶上了SHOW SLAVE STATUS\G.

除了“抽查”之外，如何检查是否正确复制了内容？例如，主/从上的帖子数量相同，这令人鼓舞。

但是，例如，当我在每个数据库上运行此查询时，我没有得到相同的答案：

select count(*) from table where datestamp >= '2016-03-24 00:00:00' AND datestamp <= '2016-03-24 23:59:59';

我是否应该担心数据丢失/不正确？数据库之间的时间戳会关闭是否有原因？

我不想重新设置复制，但我准备这样做。

谢谢你。

Answer 1

您能够发出单个 skip slave 语句并且它赶上的原因是因为 SQL 线程已停止，但 IO 线程仍在继续。

只要你看到：

Slave_IO_Running: Yes

当您运行时SHOW SLAVE STATUS，从站能够不断地从主站拉取二进制日志并将它们存储到中继日志中。

不管expire_logs_daysmaster上的设置如何，如果binlog消失了，只要被拉取到slave上的relay log中，就可以重放。

需要注意的是，在非常繁忙的服务器上，重放超过 10 天的中继日志比进行全新恢复要长得多。

关于您的计数差异，您可能遇到与此复制事件无关的其他问题。如果不访问 binlogs、schema 和 my.cnf，就很难准确地知道。

一些粗略的调试步骤：

• 复制事件之前的天数是否完全不同？之后的其他日子有什么不同吗？

• 使用工具获取奴隶和主人的差异。我推荐pt-table-checksum，但要注意以 RBR/MIXED binlog_format 运行的服务器的限制：

  pt-table-checksum 需要基于语句的复制，并且它在 master 上设置 binlog_format=STATEMENT，但由于 MySQL 的限制，副本不支持此更改。因此，校验和不会复制过去使用基于行的复制的任何副本，这些副本是进一步副本的主副本。

• 调试校验和过程发现的任何差异的根本原因。这可能有很多原因。想到的一对是在某些情况下使用基于语句的复制，或者在主从上使用不同的时区设置。

• 要解决直接差异，您可以使用pt-table-sync或恢复主副本的新副本。