谈谈 MySQL 延迟复制的几个好处

MySQL 的主从复制( Replication )关系，不太严谨的叫法是 “同步” 或者 “主从同步”。实际上在早期，MySQL 的主从并不能实现真正的 “同步”( Sync )，而是 “异步” 的( Async )。

MySQ L主从复制它可以有多种模式，最经典的也是最早出现的异步复制( Async Replication )，从 MySQL 5.5 版本开始有了半同步复制( Semi-Sync Replication)，到了 MySQL 5.7 又有了增强半同步。

本文要讨论的延迟复制，也是在 MySQL 5.6 之后才有的功能，在这之前需要用 Percona 的 pt-slave-delay 工具来变相实现。

另外，从 MySQL 5.6 版本开始增加了并行复制，不过这时还是基于 Schema 的并行模式（ slave-parallel-type=DATABASE ），效率非常差，意义不大。到了 MySQL 5.7，才实现了真正的并行复制（ slave-parallel-type=LOGICAL_CLOCK ），复制效率提升很多；还有新增了多源复制，很方便的就能实现多主一从的架构。

了解完 MySQL 复制的简史，我们切入主题。

MySQL 延迟复制的好处主要有几点：

1. 误删除时，能更快恢复数据。有时候手抖了，把线上数据给误删除了，或者误删除库、表、其他对象，或不加 WHERE 条件的更新、删除，都可以让延迟从库在误操作前的时间点停下，然后进行恢复。

2. 把延迟从库作为专用的备份节点。虽然有一定的延迟，但并不影响利用该节点作为备份角色，也不影响生产节点数据库。

3. 还可以把延迟从库当做一些问题、案例研究的对象。个别时候，可能有些 Binlog Event 在普通从库上会有问题（例如：早期版本中无主键会导致从库更新非常慢的经典问题），这时就有时间在延迟从库上慢慢琢磨研究了。

启用延迟从库的方法也挺简单的，下面是在 MySQL 8.0 的做法：

#直接用 CHANGE MASTER TO 设置，后面的 N 单位是秒数CHANGE MASTER TO MASTER_DELAY = N

当发生误操作需要让延迟从库在某个位置上停下来时，用下面的命令：

START SLAVE  UNTIL {    #1.直到指定的 GTID 位置停下    {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set        #2.直到指定的 Binlog 位置停下    |   MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos        #3.直到指定的 Relay Log 位置停下    |   RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
    #4.直到 Slave上多个并行线程之前没有延迟差距了就停下    #因为多线程复制，不同线程的复制进度不一样，因此有差距    |   SQL_AFTER_MTS_GAPS  }

注：从 MySQL 5.7 起，修改 MASTER_DELAY 选项可以在线立即生效，而无需重启 Slave 线程。

至于具体 MASTER_DELAY 设置多少合适，要估算如果发生误操作时，DBA 平均能到现场的时间，一般建议 1 小时左右。

来源：老叶茶馆 原文：http://t.cn/zTbKFUJ 题图：来自谷歌图片搜索 版权：本文版权归原作者所有 投稿：欢迎投稿，投稿邮箱: editor@hi-linux.com

今日思想

世间最珍贵的不是 “得不到” 和 “已失去”，而是现在能把握的幸福。

—— 苏格拉底