DR Auto-Sync 用户手册索引

专栏 - 同城双中心自适应同步方案 —— DR Auto-Sync 详解 | TiDB 社区

专栏 - DR Auto-Sync 搭建和计划内切换操作手册 | TiDB 社区

专栏 - DR Auto-Sync 搭建和灾难恢复手册 | TiDB 社区

一、版本选择及方案限制

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 = 0syncsync✔✔syncasync✔❌asyncasync✔❌sync_recoversync_recover❌❌

四、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 恢复流程

通过同城容灾中心的 PD 的 DR_STATE 文件，确认故障前的复制状态为 sync-recover，否则不需要进行 ACID 恢复。 cat /data1/sa_cluster_1/pd_data/DR_STATE {"state":"sync-recover","state_id":2158}

确认 pause-region-split 自上一次进入 sync 复制状态后，未被关闭过。（6.1.0 版本仍需人工判断。后续版本会在 DR_STATE 文件中提供相关标记。）

参考本手册 专栏 - DR Auto-Sync 搭建和灾难恢复手册 | TiDB 社区，对同城容灾中心进行灾难恢复。

确认恢复后的集群 PD 和 TiKV 是可用的。

使用 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

连接 TiDB 检查数据的完整性和一致性。

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

经 PD http api 确认当前复制状态为 async curl http://127.0.0.1:2379/pd/api/v1/replication_mode/status

经人工确认双中心之间的网络无法在短时间内恢复连通

六、断网应急操作手册

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

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

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

具体的操作顺序如下：

网络断连

经 PD http api 确认当前复制状态为 async curl http://127.0.0.1:2379/pd/api/v1/replication_mode/status

经人工确认双中心之间的网络无法在短时间内恢复连通

使用 dumpling 对集群进行全量备份

通过 pd-ctl 关闭 ACID 恢复功能 config set replication-mode dr-auto-sync pause-region-split false

及时将全量备份（含日常的全量备份）的拷贝运送至容灾中心存储

网络重连

集群重新恢复至 sync 模式运转

通过 pd-ctl 重新开启 ACID 恢复功能 config set replication-mode dr-auto-sync pause-region-split true

七、附录

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

config set replication-mode majority