MySQL 延迟从库介绍

前言：

我们都知道，MySQL 主从延迟是一件很难避免的情况，从库难免会偶尔追不上主库，特别是主库有大事务或者执行 DDL 的时候。MySQL 除了这种正常从库外，还可以设置延迟从库，顾名思义就是故意让从库落后于主库多长时间，本篇文章我们一起来了解下 MySQL 中的延迟从库。

延迟从库介绍

延迟复制是一种特殊的复制策略，它允许从库在主库执行完数据变更后延迟一段时间再将这些变更同步到从库。这项功能从 MySQL 5.6 版本开始得到支持，区别于传统的异步复制（接近实时），比如用户误删除了重要的表，延迟复制特性保证了用户有机会从延迟的 slave 中恢复误删除的表。延迟特性是在 slave 中实现的，不会影响 master，relay log 的接收等，只是 sql_thread 执行更新的过程延迟了指定的时间。

配置延迟从库的方法是，在从库上执行 STOP SLAVE; 命令暂停复制过程，然后使用 CHANGE MASTER TO MASTER_DELAY = N; 设置延迟时间（单位为秒），之后再执行 START SLAVE; 命令重新启动复制过程
。在监控延迟从库状态时，可以通过 SHOW SLAVE STATUS \G 命令查看 SQL_Delay 和 Seconds_Behind_Master 参数，其中 SQL_Delay 表示设置的延迟时间，Seconds_Behind_Master 表示当前从库真正延迟的时间，正常情况下 Seconds_Behind_Master = SQL_Delay。

延迟从库使用场景

对比正常从库，延迟从库会落后于主库固定的时间，比如设置 3 小时或 6 小时，这样主库的更新操作会在 3 小时或 6 小时后在延迟从库执行。想象一下，若人为或程序 bug 误操作了数据，那我们是不是可以利用延迟从库来进行快速恢复，因为此时延迟从库还未执行到这个误操作的 SQL 。显而易见，延迟从库最大的应用场景就是用于快速恢复数据，对比筛选 binlog 或从备份中恢复这两种方式，延迟从库恢复都要简单便捷许多，特别是对于数据量比较大的实例。延迟从库恢复也有两种情况，一种是误操作的这个表变动很少，那么我们直接就可以在延迟从库上备份此表，然后导入主库即可。另一种情况是按时间点恢复，首先找到误操作语句的 GTID 或 position 点位，然后停止延迟从库同步进程，取消延迟，使用 START SLAVE UNTIL 语法指定条件，让同步进程在指定 gtid 点停下，这样这个延迟从库整体就回放到主库误操作前的时间点了，具体示例操作如下：

#在主库找到误操作的gtid，再往上一条gtid，设置同步截止点
mysql> STOP SLAVE;
mysql> change master to master_delay=0;
mysql> START SLAVE UNTIL SQL_AFTER_GTIDS