黑匣子容灾—基于黑匣子的异地流式容灾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方案