黑匣子容灾—基于黑匣子的异地流式容灾RPO=0方案
作者:汤正、张耀、胡钦涵
{tangzheng14, zhangyao83, huqinhan}@huawei.com
摘要
为解决异地容灾RPO!=0的挑战难题,借用黑匣子这一可靠的存储介质,通过高斯数据库并行写黑匣子关键技术,最大限度降低对主机业务的影响,通过通过主动同步/异步刷盘自动切换关键技术,降低黑匣子故障对业务的影响,从而达成在黑匣子正常的前提下,灾难发生时,异地容灾集群升主不丢失数据。同时借助异地流式容灾的组件解耦、并发调度等技术,将异地流式容灾恢复业务的时间压缩到15秒内,对RTO、RPO做到了兼容,并且相对于不使用黑匣子的场景,性能影响小于5%。
问题背景
以工商银行、建设银行为代表的金融客户需要一种安全、数据无损恢复的黑匣子解决方案,以解决以下问题:
- 盗库/锁库,勒索频发;传统备份机制经常遭受攻击,容易丢失数据,需构建更高安全数据隔离恢复能力;
- 异地容灾当前通常采用异步复制的方式,当生产集群发生灾难,会出现丢数,导致RPO!=0的情况;
- 而容灾场景下RPO=0和性能很难兼得:
- 同步复制:同步复制是保障RPO=0的前提,但是跨千公里的TCP网络目前在20ms+,采用同步的方式就会导致主集群交易响应时延劣化几十ms,这对交易数据库是不可接受的;
- 异步复制:日志同步采用异步的方式,不会阻塞主集群的事务提交,对性能几乎无影响,但是灾备集群的数据落后于主集群,一旦发生灾难,数据会丢!
系统架构
挑战:
- 日志黑匣子作为关键部件,必须提供高可靠极致,同时保证写入时延最低降低对主集群的影响;
- 保证主备集群间的数据一致性,防止主备集群同时写入日志;
- 一套黑匣子要支持多套数据库实例,要保障租户间数据隔离;
- 降低数据库适配的成本;
- 灾难发生时,容灾集群如何获取黑匣子数据;
① 事务提交
- 数据库向本地和备机同步日志,同时向黑匣子下刷日志
- 存储引擎在判断事务提交时,需要等待大多数的备机和黑匣子
- 黑匣子故障时,主动同步/异步刷盘切换,降低黑匣子故障对业务的影响
② 容灾同步
- 容灾通过主备流式链路接受日志,并回放
③ 容灾升主
- 数据库选出新主,并从本地进行恢复
- 从黑匣子上读取日志文件
- 如果黑匣子日志更多,则从黑匣子加载差额日志进行恢复,并同步给其他备机
- 如果黑匣子上的日志没有本地多,则需要给黑匣子补发
④ 黑匣子切换
- 卸载远端黑匣子,挂载本地黑匣子
- 从本地补刷需要的日志到黑匣子
高斯数据库并行写黑匣子/备机及恢复流程
-
并行写备机和黑匣子可以最大限度降低对主机业务的影响;
-
正常刷盘流程如下:
- 数据库向本地和备机同步日志
- 同时向黑匣子下刷日志
- 存储引擎在判断事务提交时,需要等待大多数的备机和黑匣子
-
数据库主备倒换流程:
-
- 数据库选出新主,并从本地进行恢复
-
- 从黑匣子上读取日志文件
- 如果黑匣子日志更多,则从黑匣子加载差额日志进行恢复,并同步给其他备机
-
- 如果黑匣子上的日志没有本地多,则需要给黑匣子补发;
-
主动同步、异步刷盘倒换
-
数据库初始化黑匣子 Client时,注册同步转换回调函数,该函数具备两种功能
-
A、通知数据库同步和异步倒换;
-
如果数据库当前为同步事务提交判断,则修改为异步事务提交判断,不再等黑匣子写成功返回
- 约束:黑匣子故障倒换期间RPO != 0;
- 黑匣子故障倒换规格5s;
- 写超时时间可配置,例如:配置到1秒;
-
如果数据库当前为异步事务提交判断,则修改为同步事务提交判断;
-
-
B、通知数据库日志补发:
- 事务异步提交判断时,黑匣子 Client会缓存用户请求,当故障恢复后,进行补发
- 异常:当cache满后,数据需要淘汰,当cache的数据不满足连续条件时,需要数据库进行补发
-
-
此时如果数据库也发生故障倒换,参见并行刷日志恢复流程
- Tradeoff:check 黑匣子日志落后数据,判断是否需要日志全部补发后再提供服务。
未来工作
- 安全备集群:从安全角度出发,移除原有的流式复制链路,打造安全可靠的备集群
- 多集群部署适配:在现有的两地三中心部署下,也支持异地的黑匣子部署,打造同城、异地rpo均为0方案