异步容灾，AntDB的业务不间断数据恢复方案
原创异步容灾，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故障运行近十年。
AntDB电信级核心交易数据库-服务全国24个省份超10亿用户异步容灾，AntDB的业务不间断数据恢复方案
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。