DR Auto-Sync 的 ACID 恢复功能简介和长期断网应急处理方案

【是否原创】是
【首发渠道】TiDB 社区
【正文】

DR Auto-Sync 用户手册索引

| 同城双中心自适应同步方案 —— DR Auto-Sync 详解
| DR Auto-Sync 搭建和计划内切换操作手册
| DR Auto-Sync 的 ACID 恢复功能简介和长期断网应急处理方案
| DR Auto-Sync 搭建和灾难恢复手册

一、版本选择及方案限制

1.1 版本选择

请在 6.1.0 或更高版本上使用 DR Auto-Sync 功能。

二、前言

DR Auto-Sync 是一种跨同城两中心(网络延迟 <1.5ms,带宽 >10Gbps)部署的单一集群方案,即两个数据中心只部署一个 TiDB 集群,两中心间的数据复制通过集群自身 Raft 机制完成。两中心可同时对外进行读写服务,任一中心发生故障不影响数据一致性。

图 1

三、灾难恢复概览

3.1 不同复制状态下的灾难恢复策略

在发生主中心整体故障时,所有 Region 都失去了大多数副本,因而集群无法提供服务,我们需要使用从中心的数据来恢复服务,恢复的能力根据故障前的复制状态决定:

  • 如果故障前处于同步复制状态(状态码为 sync),可使用从中心数据进行 RPO = 0 的数据恢复。
  • 如果故障前处于异步复制状态(状态码为 async),使用从中心数据恢复服务后,会丢失主集群在异步模式下写入的数据。这种情况的典型场景是,主集群完全故障前,先发生了主从断连,且主集群切换至异步复制状态并提供了一段时间服务。
  • 如果故障前处于异步切换同步状态(状态码为 sync-recover),使用从中心数据恢复服务后,会丢失一部分主集群在异步模式下写入的数据,并且可能会发生数据 ACID 不一致的情况,需要进行额外的 ACID 一致性恢复操作。这种情况的典型场景是,先发生了主从断连,切换至异步模式写入一些数据后,主从中心连接恢复,在主从中心同步数据的过程中,再次发生故障,并导致主中心整体不可用。

3.2 危险的复制状态 sync_recover

在 DR Auto-Sync 的三个暴露给用户的复制状态中,sync_recover 是最为特殊的一个,进入 sync_recover 状态意味着容灾中心 TiKV 开始接收主中心 region leader 传来的数据,而 TiKV 的 multi-raft 架构特性,导致了无法控制各 region 按照 tso 的顺序进行复制,也就是说在对 sync_recover 状态的容灾副本进行数据恢复后,数据是不具备 ACID 一致性的。

一个典型的案例是:账户余额表中 A,B 两账户位于两个 region 上,发生了一笔从 B 到 A 的转账交易,在 sync_recover 状态下, B 出账的数据先于 A 入账的数据落实在了容灾副本上,此时若发生主中心损毁,通过容灾副本进行数据恢复后,就会出现数据不一致的问题。

下表列举了 DR Auto-Sync 在各状态下的容灾能力:

容灾中心 PD 的 DR_STATE 状态文件 PD http api(能访问则说明 PD 多副本存活) 容灾副本是否具备 ACID 一致性 容灾中心 RPO = 0
sync sync :heavy_check_mark: :heavy_check_mark:
sync async :heavy_check_mark: :x:
async async :heavy_check_mark: :x:
sync_recover sync_recover :x: :x:

四、DR Auto-Sync 的 ACID 恢复功能简介

4.1 ACID 恢复功能简介

TiKV 正常运行时,所有 region 会各自落实所有已提交的 raftlog,前文提到的的危险复制状态 sync_recover 是由这种机制引起的。

从 v6.1.0 版本开始,DR Auto-Sync 处于同步复制状态的时候,可以定期记录一个 ts 作为 checkpoint TS,用于标记可以安全回滚数据到该 TS。

ACID 恢复时,通过 tikv-ctl 工具扫描删除所有 commit ts 大于恢复 timestamp 的 write CF 数据及对应的 default CF 数据,运行一次全部数据的 resolve lock 清除残留的 lock CF 数据及其对应的 default CF 数据,即可将 TiKV 数据回滚到 ACID 一致的状态。

4.2 启用 DR Auto-Sync 的 ACID 恢复功能

通过 pd-ctl 工具开启 DR Auto-Sync 的 ACID 恢复功能。将该参数设置为 true 时,禁止 async 复制状态下的 region 分裂,即开启 ACID 恢复功能。

config set replication-mode dr-auto-sync pause-region-split true

需要注意:该功能须提前启用,如果进入 async 状态后再启用,将无法保障灾备副本在下一次进入 sync_recover 复制状态的 ACID 恢复能力。

4.3 ACID 恢复流程

  1. 通过同城容灾中心的 PD 的 DR_STATE 文件,确认故障前的复制状态为 sync-recover,否则不需要进行 ACID 恢复。
    cat /data1/sa_cluster_1/pd_data/DR_STATE
    {“state”:“sync-recover”,“state_id”:2158}
  2. 确认 pause-region-split 自上一次进入 sync 复制状态后,未被关闭过。(6.1.0 版本仍需人工判断。后续版本会在 DR_STATE 文件中提供相关标记。)
  3. 参考本手册 DR Auto-Sync 搭建和灾难恢复手册,对同城容灾中心进行灾难恢复。
  4. 确认恢复后的集群 PD 和 TiKV 是可用的。
  5. 使用 v6.1.0 或更高版本的 TiKV Control 工具的 reset-to-version 处理 TiKV 数据,所使用的 version 参数可以使用 pd-ctl min-resolved-ts 查得。reset-to-version 命令用于数据丢失大部分副本后,或者数据同步不完整,导致出现数据包含不完整事务的情况。此时需要提供一个更旧的能保证 ACID 一致性的版本号,tikv-ctl 会清除掉所有版本号更大的数据。
    -v 选项用于指定恢复的版本号
    tikv-ctl --host 127.0.0.1:20160 reset-to-version -v 430315739761082369
  6. 连接 TiDB 检查数据的完整性和一致性。

五、启用断网应急方案的必要条件

  1. 经 PD http api 确认当前复制状态为 async
    curl http://127.0.0.1:2379/pd/api/v1/replication_mode/status
  2. 经人工确认双中心之间的网络无法在短时间内恢复连通

六、断网应急操作手册

开启 ACID 恢复功能(config set replication-mode dr-auto-sync pause-region-split true)的代价是网络断开,集群进入主中心独自以 async 状态运行时,region 将不再分裂,以保持主中心副本 region 元信息与容灾中心副本 region 的元信息一致。

保持两中心的 region 元信息一致,是为了防止在网络重新连接后,由于 region 被清除而造成部分数据出现短暂的空洞,从而对容灾中心副本的容灾能力造成毁灭性打击。

当人工确认双中心之间的网络无法在短时间内恢复时,可以关闭 ACID 恢复功能来降低大 region 对集群性能造成的影响。但关闭了 ACID 恢复功能,也就宣告了容灾中心副本在网络连通进入 sync_recover 状态时,将不具备一致性的数据恢复能力。因此我们为了保障容灾中心的容灾能力,需要在关闭 ACID 恢复功能前,对主中心进行全量备份,并及时将该备份文件运送拷贝至容灾中心保存。同时在网络断开期间,对于日常的全量备份,也都应当及时的运送拷贝至容灾中心存储,以加强容灾中心的保障能力。

具体的操作顺序如下:

  1. 网络断连
  2. 经 PD http api 确认当前复制状态为 async
    curl http://127.0.0.1:2379/pd/api/v1/replication_mode/status
  3. 经人工确认双中心之间的网络无法在短时间内恢复连通
  4. 使用 dumpling 对集群进行全量备份
  5. 通过 pd-ctl 关闭 ACID 恢复功能
    config set replication-mode dr-auto-sync pause-region-split false
  6. 及时将全量备份(含日常的全量备份)的拷贝运送至容灾中心存储
  7. 网络重连
  8. 集群重新恢复至 sync 模式运转
  9. 通过 pd-ctl 重新开启 ACID 恢复功能
    config set replication-mode dr-auto-sync pause-region-split true

七、附录

7.1 关闭 DR Auto-Sync 功能的命令

config set replication-mode majority