MySQL复制是否会受到高延迟互连的影响？

我们有一个位于不同数据中心的原始主控和从属MySQL设置，另一个与主控位于同一数据中心的从属。

数据中心之间的带宽相当高（在网络基准测试中，我们可以达到15MB /秒），但存在延迟，大约为28ms。无论如何它都不算高，但是比同一个数据中心的亚秒级延迟要高得多。

有时，在删除从属服务器时，我们会遇到严重的延迟（2000秒以上），而本地从属服务器会保持最新状态。当查看滞后的远程从属服务器时，SQL线程通常会花费时间等待IO线程更新中继日志。母版同时显示“等待网络”或类似信息。

因此，这意味着它是网络，但是在发生这种情况时，我们仍然拥有可用带宽。

我的问题是：数据中心之间的延迟会影响复制性能吗？从属io线程只是在主事件停止发送事件之前一直传输事件，还是在事件之间以某种方式合并主事件？

您问题的直接答案是“是”，但这取决于您所运行的MySQL版本。在MySQL 5.5之前，复制操作如下：

• 主执行SQL
• 主记录SQL事件在其二进制日志中
• 从站从主二进制日志读取SQL事件
• 从站通过I / O线程将SQL事件存储在其中继日志中
• 从站通过SQL线程从中继日志中读取下一个SQL事件
• 从站执行SQL
• 从站确认SQL事件已完全执行

从MySQL 5.5开始，使用Semisynchronous Replication，现在复制将按以下方式运行：

• 主执行SQL
• 主记录SQL事件在其二进制日志中
• 从站从主二进制日志读取SQL事件
• 从站确认SQL事件的接收主机
• 从站通过I / O线程将SQL事件存储在其中继日志中
• 从站通过SQL线程从中继日志中读取下一个SQL事件
• 从站执行SQL
• 从站确认SQL事件已完全执行

这个新的范例将使从站与其主站更紧密地同步。

尽管如此，网络内部的延迟可能会阻碍MySQL半同步复制，使其恢复为旧式异步复制。为什么呢 如果发生超时而没有任何从属确认事务，则主控将还原为异步复制。当至少有一个半同步从属服务器赶上时，主服务器将返回到半同步复制。

更新2011-08-08 14:22 EDT

MySQL 5.5半同步复制的配置非常简单

步骤1）将这四（4）行添加到/etc/my.cnf

[mysqld]
plugin-dir=/usr/lib64/mysql/plugin
#rpl_semi_sync_master_enabled
#rpl_semi_sync_master_timeout=5000
#rpl_semi_sync_slave_enabled

步骤2）重新启动MySQL

service mysql restart

步骤3）在MySQL客户端中运行这些命令

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave  SONAME 'semisync_slave.so';

步骤4）在plugin-dir选项之后取消注释三个rpm_semi_sync选项

[mysqld]
plugin-dir=/usr/lib64/mysql/plugin
rpl_semi_sync_master_enabled
rpl_semi_sync_master_timeout=5000
rpl_semi_sync_slave_enabled

步骤5）重新启动MySQL

service mysql restart

全部做完 ！！！现在，像往常一样设置MySQL复制。

我非常喜欢Rolando如何描述复制执行的操作顺序。但是，我认为如果添加其他组件（客户端）会更清楚。

使用客户端，异步复制的操作顺序如下：

1. 客户端使用事务向主服务器发送SQL查询（例如，插入）

2. 主人执行交易。如果成功，则将记录存储在磁盘上，但尚未提交事务。

3. 主服务器在主二进制日志中记录插入事件。如果主服务器无法将其存储在二进制日志中，则事务将回滚。

4. 客户端收到主服务器的响应（成功或回滚）。

5. 如果事务成功，主服务器上的转储线程将从二进制日志中读取事件，并将其发送到从属I / O线程。

6. 从属I / O线程接收该事件并将其写入中继日志文件的末尾。

7. 一旦事件进入中继日志，从属SQL线程就会执行
   该事件，以将更改应用于从属服务器上的数据库。

在这种情况下，主服务器不关心从服务器，而客户端仅通过手动执行“ SHOW SLAVE STATUS”命令知道从服务器上有问题。

在半同步复制的情况下，操作顺序可能如下：

1. 客户端使用事务向主服务器发送SQL查询（例如，insert）。

2. 主人执行交易。如果成功，记录将存储在磁盘上，但不会提交事务。

3. 主服务器将插入事件记录在主二进制日志中。如果主服务器无法将其存储在二进制日志中，则事务将回滚，并且只有在回滚的情况下，客户端才会收到响应。

4. 由于主服务器上事务的成功，主服务器上的转储线程从二进制日志中读取事件，并将其发送到从属I / O线程。

5. 从属I / O线程接收该事件并将其写入中继日志文件的末尾。

6. 从机确认在中继日志文件中记录事件的主设备。

7. 主机提交插入事务。

8. 客户端收到主服务器的响应（成功）。

9. 一旦事件进入中继日志，从属SQL线程就会执行
   该事件。主机和客户端不知道执行是否成功。

半同步复制解决了一个重要情况，即从属服务器或网络死亡，主服务器继续运行。然后，主节点死亡，您只想因为修复了该节点就想将旧的从节点重新启动为新的主节点。

因此，您将该节点作为新的主节点启动，修复了旧的主节点，现在想将其用作从节点。该节点仍具有数据，但是如果新的从属节点从新的主节点开始的位置开始，将有重复的记录。

如果等待时间是无限的，则假定从站上的所有查询均成功，则主站二进制日志位置将始终与从站中继日志位置同步。这个假设有多现实？

我认为这是非常现实的。从属查询失败的最常见情况之一是“重复记录”。如果主记录没有，重复记录到从记录中去了？它来自错误的位置，该位置已分配给从服务器以开始复制。起始复制位置包括已复制的记录。如果是半同步复制，则不会发生这种情况。

雅各布·尼康（Jacob Nikom）

限定词：我不是MySQL用户，所以大多数情况下，这只是我对互联网的研究。

如您所知，MySQL复制的最大局限在于它是单线程的。因此，当线程忙于将数据发送到内部从服务器时，它将无法将数据发送到远程从服务器。这是这里。

每在这里：

您需要确保做的一件事是减少交易时间。这使您的复制线程有机会赶上数据库中发生的事情。您希望您的交易尽可能短。

一种方法是通过查询斩波。通过使用WHERE子句限制UPDATE或DELETE更改的行。如果将其置于循环中，则可以遍历列表，每次都启动和提交事务。（在各自的事务中，分别更新/删除第一个三分之一，第二个三分之一，然后最后一个三分之一。）我个人强烈建议您不要这样做，因为您可以自行决定表中数据在事务之间更改的可能性。但是，如果您确定没有其他人弄乱表（并且永远不会），则有可能提高此性能。

另一种可能性是不复制那些长时间运行的事务，而是在两个主服务器（复制到本地从服务器）上运行它们，然后分别在远程从服务器上运行它们。这将释放复制线程，以便不会陷入30分钟以上的停顿。

每在这里：

最后一种可能性是调整TCP缓冲区的大小。目的是减少您在主站和从站之间进行的通信数量。这可以帮助减少延迟。

就个人而言，如果其他所有方法都失败，我会尝试这样做。我怀疑该问题更多是由单线程复制系统而不是网络延迟引起的。网络通常会在30分钟标记之前超时。（30分钟？！）

JHammerb的Delicious书签具有几个用于mysql复制的链接，您也可能需要检查一下。

希望对您有所帮助。