异步容灾，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

延迟复制灾备方案的示例

本章节介绍了环境信息、搭建主备复制、主备数据一致性验证、延迟复制的设置、延迟复制的验证。

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故障运行近十年。