黄东旭解析 TiDB 的核心优势
586
2024-04-25
专栏 - 同城双中心自适应同步方案 —— DR Auto-Sync 详解 | TiDB 社区
专栏 - DR Auto-Sync 搭建和计划内切换操作手册 | TiDB 社区
专栏 - DR Auto-Sync 搭建和灾难恢复手册 | TiDB 社区
请在 6.1.0 或更高版本上使用 DR Auto-Sync 功能。
DR Auto-Sync 是一种跨同城两中心(网络延迟 <1.5ms,带宽 >10Gbps)部署的单一集群方案,即两个数据中心只部署一个 TiDB 集群,两中心间的数据复制通过集群自身 Raft 机制完成。两中心可同时对外进行读写服务,任一中心发生故障不影响数据一致性。
图 1
在发生主中心整体故障时,所有 Region 都失去了大多数副本,因而集群无法提供服务,我们需要使用从中心的数据来恢复服务,恢复的能力根据故障前的复制状态决定:
如果故障前处于同步复制状态(状态码为 sync),可使用从中心数据进行 RPO = 0 的数据恢复。
如果故障前处于异步复制状态(状态码为 async),使用从中心数据恢复服务后,会丢失主集群在异步模式下写入的数据。这种情况的典型场景是,主集群完全故障前,先发生了主从断连,且主集群切换至异步复制状态并提供了一段时间服务。
如果故障前处于异步切换同步状态(状态码为 sync-recover),使用从中心数据恢复服务后,会丢失一部分主集群在异步模式下写入的数据,并且可能会发生数据 ACID 不一致的情况,需要进行额外的 ACID 一致性恢复操作。这种情况的典型场景是,先发生了主从断连,切换至异步模式写入一些数据后,主从中心连接恢复,在主从中心同步数据的过程中,再次发生故障,并导致主中心整体不可用。
在 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 = 0syncsyncsyncasyncasyncasyncsync_recoversync_recoverTiKV 正常运行时,所有 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 一致的状态。
通过 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 恢复能力。
通过同城容灾中心的 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
config set replication-mode majority
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。