mysql 复制在什么情况下可能会中断？

Question

我在主/从配置模式下运行 mysql 服务器。有多个从主从复制。它们工作正常并且它们的复制状态受到监控。

其中一名奴隶为特殊目的服务。开发人员给了我一组要在从属 A 上复制的从属数据库上运行的更新查询。

他们正在更新数据库表中的旧记录（修改大量记录的列数据）。

问题

• 有什么办法可以弄清楚给定的查询是否会破坏复制？
• 对于将来，我如何确定查询是否会破坏复制？

Answer 1

鉴于 MySQL Replication 是双线程的，因此了解 Replication 在发生故障时的样子非常重要。该领域有四个主要主题

SQL 线程终止

SQL线程负责

• 从中继日志获取下一条 SQL 语句
• 执行SQL语句
• 通过删除已执行所有 SQL 条目的任何中继日志来轮换中继日志

如果发生任何 SQL 错误，SQL 线程就会终止，并将以下内容发布到其从属状态：

• 错误号
• 错误信息
• 遇到错误的 SQL 语句
• 当前数据库
• SQL 起源的主日志文件
• SQL 起源的主日志位置

这提供了排除故障、跳过错误、手动运行 SQL 语句、启动复制备份的机会。有时可能是基于 SQL 的错误，例如错误 1062（重复键）。其他时候，它可能与存储引擎或操作系统有关。

要确定 SQL 语句是否会中断复制，您应该采用任何 DML（INSERT、UPDATE 或 DELETE）并使用 DML 的 WHERE 子句进行相应的 SELECT。然后，运行该 SELECT 来查看您要操作的数据是否确实存在。

I/O 线程模具

I/O 线程负责四 (4) 件事：

• 从Master的二进制日志条目下载SQL
• 将 SQL 作为 FIFO 队列记录到其本地中继日志中
• 确认通信失败
• 尝试重建 I/O 线程

任何网络延迟都可能导致 I/O 线程简单地终止并重试连接。有时，在这种情况下，从站对主站日志文件和位置（在其中继日志中记录的）的看法可能与主站在其二进制日志中实际记录的内容不同步。

其他副作用可能包括损坏的中继日志条目

• 网络传输不良造成的，可以通过从 Slave 执行的 Master 的最后一条 SQL 语句运行 CHANGE MASTER TO 来纠正。
• 由主服务器上损坏的二进制日志条目引起，该条目已成功传输到中继日志，可以通过以下方式纠正
  • RESET MASTER;在 Master 上 Zap 所有二进制日志
  • 设置从新的当前二进制日志进行复制
  • 使用pt-table-sync来纠正差异

临时表的使用

解决这个问题就像玩“给驴钉尾巴”一样。大多数开发人员都没有意识到这一点，直到它发生并且您尝试修复它而没有意识到这种情况的原因从哪里开始。场景如下：如果您CREATE TEMPORARY TABLE在 Master 上使用，它将复制到 Slave。在使用该表期间，它将在 SQL 线程中保持存在。如果您发出STOP SLAVE;，SQL 线程将与该 SQL 线程所持有的所有临时表一起被自动终止。您不会意识到这种情况已经发生，直到您发出START SLAVE;并且 SQL 线程再次终止，因为所需的临时表不再存在。

要解决此问题，您必须对主服务器的二进制日志和复制进行手术，如下所示：

• CREATE TEMPORARY TABLE步骤 01) 找到在主服务器上发出的确切日志文件和位置
• CREATE TEMPORARY TABLE步骤 02) 找到目标数据库的名称
• CREATE TABLE使用而不是创建表CREATE TEMPORARY TABLE
• 步骤 03)CHANGE MASTER TO使用步骤 01 中的文件和位置运行
• 步骤 04) 运行START SLAVE;，直到复制赶上或另一个表的不存在（由于CREATE TEMPORARY TABLE）破坏同一问题的复制
• 步骤 05) 如果由于CREATE TEMPORARY TABLE在不同的表上复制再次中断，请返回步骤 01

网络注意事项

曾几何时，MySQL 倾向于说复制正在运行，而事实上它并未运行。当网络间歇性可能会延迟二进制日志的数据传输但不足以严重到使 I/O 线程超时时，就会发生这种情况。由于MySQL进程可能对网络有点不敏感，因此我亲切地将其称为“网络不考虑”。虽然有关此问题的错误报告已关闭，但最好有多种方法来检查 MySQL Replication 的运行能力，尤其是 I/O 线程。使用 MySQL 5.5，您可以使用以半同步复制为中心的心跳和超时参数来调整 I/O 线程的敏感度。