shl*_*oid 11 mysql replication
我们有一个位于不同数据中心的vanilla master 和slave MySQL 设置，以及与master 位于同一数据中心的另一个slave。
数据中心之间的带宽相当高（在我们所做的网络基准测试中，我们可以达到 15MB/秒），但存在延迟，约为 28 毫秒。无论如何它都不高，但它比同一数据中心的亚秒延迟要高得多。
有时，我们会在删除从站时遇到严重的滞后（2000 秒甚至更多），而本地从站保持最新。在查看滞后的远程slave时，SQL线程通常会花时间等待IO线程更新中继日志。主人同时显示“等待网络”或类似的东西。
所以这意味着它是网络，但在发生这种情况时我们仍然有免费带宽。
我的问题是：数据中心之间的延迟会影响复制的性能吗？从属 io 线程是否只是流式传输事件直到主节点停止发送它们，还是在事件之间以某种方式池主节点？
您的问题的直接答案是肯定的，但这取决于您运行的 MySQL 版本。在 MySQL 5.5 之前，复制操作如下：
从 MySQL 5.5 开始，使用半同步复制，现在复制操作如下：
这种新范式将允许从站与其主站更接近同步。
尽管如此，网络中的延迟可能会阻碍 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 复制。
限定词：我不是 MySQL 用户，所以大多数情况下，这只是我在互联网上的研究。
我相信您知道，MySQL 复制的最大限制是它是单线程的。因此，当线程忙于向内部从站发送数据时，它无法向远程从站发送数据。这是每这里。
每这里：
您需要确保做的一件事是减少交易时间。这使您的复制线程有机会赶上数据库中发生的情况。您希望您的交易尽可能短。
实现此目的的一种方法是通过查询砍伐；通过使用 WHERE 子句限制 UPDATE 或 DELETE 更改的行。如果将其放在循环中，则可以迭代列表，每次启动并提交事务。（在自己的事务中更新/删除前三分之一、第二个三分之一，然后是最后三分之一。）我个人强烈建议不要这样做，因为您会面临表中数据在事务之间发生变化的可能性。但是，如果您确定没有其他人弄乱该表（并且永远不会），则有可能提高此性能。
另一种可能性是不复制那些长时间运行的事务，而是在两个主服务器上运行它们（复制到本地从服务器），然后分别在远程从服务器上运行它们。这将释放复制线程，使其不会陷入 30 多分钟的困境。
每这里：
最后一种可能是调整 TCP 缓冲区的大小。目标是减少主设备和从设备之间进行的通信数量。这有助于减少延迟。
就我个人而言，如果其他方法都失败了，我会尝试这个。我怀疑这个问题更多是由单线程复制系统引起的，而不是网络延迟。网络通常会在 30 分钟之前很久就超时。（30分钟？！）
JHammerb 的Delicious 书签有几个有关 mysql 复制的链接，您可能也想查看一下。
我希望这有帮助。