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='0a9a0b8b-4df3-11ed-a592-fa76892aa300:21741053';
#同步到对应截止点后，SQL线程会自动停止。
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.97
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: bin-log.000151
Read_Master_Log_Pos: 39510957
Relay_Log_File: relay-log.000004
Relay_Log_Pos: 35271037
Relay_Master_Log_File: bin-log.000151
Slave_IO_Running: Yes
Slave_SQL_Running: No -> 到达设定的GTID值后，SQL线程会中断
...
Until_Condition: SQL_AFTER_GTIDS -> 设置后这里会出现同步截止的关键信息
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 60859881
Master_UUID: 0a9a0b8b-4df3-11ed-a592-fa76892aa300
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
...
Retrieved_Gtid_Set: 0a9a0b8b-4df3-11ed-a592-fa76892aa300:21562347-21747364
Executed_Gtid_Set: 0a9a0b8b-4df3-11ed-a592-fa76892aa300:1-21741053 -> 同步截止点
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
# sql线程停止代表此从库已经回放至误操作前的时间点，之后我们就能备份误操作的表然后到主库进行恢复了
除了用于快速恢复外，延迟从库还有以下应用场景：
- 备份和容错：延迟从库保留的也是一份完整的副本，可用于备份或故障切换。
- 离线查询：延迟从库可以用于离线数据处理或批量分析任务，而不影响在线服务。
- 审计和合规性：某些合规性要求可能需要保留数据的历史版本，延迟从库可以作为满足这些要求的一种手段。
总结：
通过以上介绍可以看出，延迟从库主要适用于需要增强数据安全性和提高系统可用性的场合。通过合理配置和监控，可以有效利用延迟从库的优势来增强数据库系统的稳定性、可靠性和性能。如果你的数据库实例有多个从库，不妨将其中一个设置为延迟从库，对于快速恢复数据还是很有作用的。