【Poster】黑匣子容灾—基于黑匣子的异地流式容灾RPO=0方案

黑匣子容灾—基于黑匣子的异地流式容灾RPO=0方案

作者:汤正、张耀、胡钦涵
{tangzheng14, zhangyao83, huqinhan}@huawei.com

摘要

为解决异地容灾RPO!=0的挑战难题,借用黑匣子这一可靠的存储介质,通过高斯数据库并行写黑匣子关键技术,最大限度降低对主机业务的影响,通过通过主动同步/异步刷盘自动切换关键技术,降低黑匣子故障对业务的影响,从而达成在黑匣子正常的前提下,灾难发生时,异地容灾集群升主不丢失数据。同时借助异地流式容灾的组件解耦、并发调度等技术,将异地流式容灾恢复业务的时间压缩到15秒内,对RTO、RPO做到了兼容,并且相对于不使用黑匣子的场景,性能影响小于5%。

问题背景

以工商银行、建设银行为代表的金融客户需要一种安全、数据无损恢复的黑匣子解决方案,以解决以下问题:

  • 盗库/锁库,勒索频发;传统备份机制经常遭受攻击,容易丢失数据,需构建更高安全数据隔离恢复能力;
  • 异地容灾当前通常采用异步复制的方式,当生产集群发生灾难,会出现丢数,导致RPO!=0的情况;
  • 而容灾场景下RPO=0和性能很难兼得:
  • 同步复制:同步复制是保障RPO=0的前提,但是跨千公里的TCP网络目前在20ms+,采用同步的方式就会导致主集群交易响应时延劣化几十ms,这对交易数据库是不可接受的;
  • 异步复制:日志同步采用异步的方式,不会阻塞主集群的事务提交,对性能几乎无影响,但是灾备集群的数据落后于主集群,一旦发生灾难,数据会丢!

系统架构

挑战:

  • 日志黑匣子作为关键部件,必须提供高可靠极致,同时保证写入时延最低降低对主集群的影响;
  • 保证主备集群间的数据一致性,防止主备集群同时写入日志;
  • 一套黑匣子要支持多套数据库实例,要保障租户间数据隔离;
  • 降低数据库适配的成本;
  • 灾难发生时,容灾集群如何获取黑匣子数据;

① 事务提交

  • 数据库向本地和备机同步日志,同时向黑匣子下刷日志
  • 存储引擎在判断事务提交时,需要等待大多数的备机和黑匣子
  • 黑匣子故障时,主动同步/异步刷盘切换,降低黑匣子故障对业务的影响

② 容灾同步

  • 容灾通过主备流式链路接受日志,并回放

③ 容灾升主

  • 数据库选出新主,并从本地进行恢复
  • 从黑匣子上读取日志文件
  • 如果黑匣子日志更多,则从黑匣子加载差额日志进行恢复,并同步给其他备机
  • 如果黑匣子上的日志没有本地多,则需要给黑匣子补发

④ 黑匣子切换

  • 卸载远端黑匣子,挂载本地黑匣子
  • 从本地补刷需要的日志到黑匣子

高斯数据库并行写黑匣子/备机及恢复流程

  • 并行写备机和黑匣子可以最大限度降低对主机业务的影响;

  • 正常刷盘流程如下:

    1. 数据库向本地和备机同步日志
    2. 同时向黑匣子下刷日志
    3. 存储引擎在判断事务提交时,需要等待大多数的备机和黑匣子
  • 数据库主备倒换流程:

      1. 数据库选出新主,并从本地进行恢复
      1. 从黑匣子上读取日志文件
      • 如果黑匣子日志更多,则从黑匣子加载差额日志进行恢复,并同步给其他备机
        1. 如果黑匣子上的日志没有本地多,则需要给黑匣子补发;

主动同步、异步刷盘倒换

  • 数据库初始化黑匣子 Client时,注册同步转换回调函数,该函数具备两种功能

    • A、通知数据库同步和异步倒换;

      • 如果数据库当前为同步事务提交判断,则修改为异步事务提交判断,不再等黑匣子写成功返回

        • 约束:黑匣子故障倒换期间RPO != 0;
        • 黑匣子故障倒换规格5s;
        • 写超时时间可配置,例如:配置到1秒;
      • 如果数据库当前为异步事务提交判断,则修改为同步事务提交判断;

    • B、通知数据库日志补发:

      • 事务异步提交判断时,黑匣子 Client会缓存用户请求,当故障恢复后,进行补发
      • 异常:当cache满后,数据需要淘汰,当cache的数据不满足连续条件时,需要数据库进行补发
  • 此时如果数据库也发生故障倒换,参见并行刷日志恢复流程

    • Tradeoff:check 黑匣子日志落后数据,判断是否需要日志全部补发后再提供服务。

未来工作

  • 安全备集群:从安全角度出发,移除原有的流式复制链路,打造安全可靠的备集群
  • 多集群部署适配:在现有的两地三中心部署下,也支持异地的黑匣子部署,打造同城、异地rpo均为0方案