异步容灾，AntDB 的业务不间断数据恢复方案
当业务对数据库进行了误操作，导致了数据的丢失或其他问题的发生。此时，虽然可以通过备份恢复或数据闪回等方式能够对数据库进行恢复，但是该过程可能会导致业务出现较长时间的中断，最终影响业务系统的稳定性。
在这种场景下，AntDB 数据库提供了延迟复制的容灾方案，可以供业务进行快速恢复，给出了一种新的数据恢复解决方案，本文对这种延迟复制的容灾方案进行了探索。
关键词：同步复制；异步复制；延迟复制；数据库参数
01
数据库容灾概述
在业务误删除数据的情况下，可以使用 AntDB 数据库提供的延迟复制的容灾方案，对误删除数据进行快速恢复，保证业务系统的稳定运行。
02 AntDB 延迟复制的原理
本章节介绍了复制的基本原理、延迟复制的基本原理、AntDB 数据库延迟复制的适用场景。
2.1 复制的基本原理
线上运行的数据库，通常都会采用高可用部署来确保数据库的稳定运行。AntDB 数据库在进行高可用部署的时候，可支持如下两种模式：
同步复制高可用：一个事务的所有修改都被传送到一台或者多台同步后备服务器后，AntDB 数据库才会认为该事务正常执行。
图 1：AntDB 同步复制原理
异步复制高可用：一个事务在主库上执行成功后（不管后备服务器是否接收到了该事务相关的信息），AntDB 数据库就认为该事务正常执行。
图 2：AntDB 异步复制原理
2.2 延迟复制的基本原理
默认情况下，备库异步复制获取到了数据文件之后，立即回放接收到的数据文件；保证主库上已经提交的事务能够在备库上也提交，从而保证主备数据的一致性。
延迟复制的功能，是建立在异步复制的基础上支持的功能；可以通过配置相应的参数，来控制数据文件何时在备库中进行回放。
以股市 T+1 业务为例介绍延迟备库：
股市业务中 T+1：T 时间点交易结束，资金需要延迟 1 个交易日才会到账（假设下一个交易日是工作日）。
延迟备库中 T+N：T 时间点交易结束，备库需要延迟 N 时间后才会在备库进行数据文件的回放。
# 主库：事务提交时间为 T
# 延迟备库：事务提交时间为 T+N
具体的 AntDB 数据库处理流程，可以参考下图：
图 3：AntDB 延迟复制的原理
2.3 AntDB 数据库延迟复制的适用场景
通过上述描述，可以获得延迟复制的适用场景：
巨量数据库备份恢复的补充方案，可以有效降低成本。
若主库 T 时间点误操作（仅指 DML 操作，对于 Truncate、Drop 等 DDL 无效），可以在 N 时间段内完成 T 时间点内的数据恢复，这是因为备库延迟至 T+N 时间点，才会开始 WAL 日志流重做。
03
AntDB 延迟复制灾备方案的示例
本章节介绍了环境信息、搭建主备复制、主备数据一致性验证、延迟复制的设置、延迟复制的验证。
3.1 环境信息
在如下环境中部署 AntDB 高可用环境：
3.2 搭建主备复制
1.10.21.13.207 构建主库：
2. 10.21.13.208 构建备库：
3. 检查复制状态
图 4：10.21.13.207 复制状态检查结果
图 5：10.21.13.208 复制状态检查结果
结论：AntDB 数据库主备复制关系已经搭建正常。
3.3 主备数据一致性验证
10.21.13.207：
图 6：10.21.13.207 数据的查询
图 7：10.21.13.208 数据的查询
结论：主备数据保持一致。
3.4 延迟复制的设置
10.21.13.208 上通过设置 AntDB 数据库参数 recovery_min_apply_delay 来设置延迟复制。
图 8：10.21.13.208 上设置延迟复制参数
结论：AntDB 数据库延迟复制参数已经设置生效。
3.5 延迟复制的验证
3.5.1 DML 的验证
10.21.13.207 进行 DML 的验证：
图 9：10.21.13.207 上进行 DML 的验证
10.21.13.208 进行 DML 的验证：
图 10：10.21.13.208 上进行 DML 的验证
结论：主库上的 SQL 瞬间执行完成；备库的数据日志回放，正常按照延迟复制参数进行的（1min）。
3.5.2 DML 误操作时的恢复
1. 10.21.13.207 上误删除
图 11：10.21.13.207 上的误删除数据
2. 10.21.13.208 上误删除数据获取
图 12：10.21.13.208 上的误删除数据的获取
3. 10.21.13.207 上恢复误删除数据并确认
图 13：10.21.13.207 上的误删除数据的恢复
4. 10.21.13.208 上恢复数据的确认
图 14：10.21.13.208 上的误删除数据的验证
结论：主库上的 DML 误操作后，1min 内将误操作的数据从备库上可导出。导出的数据可在主库上进行恢复。恢复后的数据保持一致。
3.5.3 Truncate 的验证
10.21.13.207：
图 15：10.21.13.207 上的 truncate
10.21.13.208：
图 16：10.21.13.208 上的查询等待
结论：主库上的 truncate 立即执行完成；备库检测到 truncate 时，会等待当前的 select，查询等待时间为 1min。
3.5.4 drop table 的验证
10.21.13.207：
图 17：10.21.13.207 上的 drop
10.21.13.208：
图 18：10.21.13.208 上的查询等待
结论：主库上的 drop 立即执行完成；备库检测到 drop 时，会等待当前的 select，查询等待时间为 1min。
04 探索总结
综上所述，在 AntDB 数据库的延迟复制的机制下，当业务对数据库进行了误删除数据时，可以通过导出延迟备库的数据来对主库数据进行修复。AntDB 数据库能够实现业务的快速恢复，保障核心系统的稳定运行，从而有力支撑了业务的稳定性和连续性，提升了终端用户的体验。
关于我们
AntDB 数据库始于 2008 年，在运营商的核心系统上，为全国 24 个省份的 10 亿多用户提供在线服务；广泛应用于通信、金融、交通、能源、物联网等行业，在 200 多个项目上成功落地。AntDB 数据库具备高性能、弹性扩展、高可靠等产品特性，峰值每秒可处理百万笔电信核心交易，并保障系统持续 0 故障运行近十年。
版权声明: 本文为 InfoQ 作者【亚信AntDB数据库】的原创文章。
原文链接:【http://xie.infoq.cn/article/fc2b41be77820672b322eab5a】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
企业数据库创新实践者 2021.07.26 加入
AntDB数据库始于2008年，服务于全国20多个省份的10亿多用户提供在线服务；具备高性能、弹性扩展、高可靠等产品特性，峰值每秒可处理百万笔电信核心交易，并保障系统持续0故障运行近十年。 官网：asiainfoah.com
评论