课程名称：3.9.4 Mutil Site Disaster Recovery （TiDB 跨数据中心部署方案）
学习时长：10min
课程收获：
在多副本异常情况下，保障集群正常可用
课程内容：
1.造成数据丢失的几种情况
-
常见情况
- 某些region的全部副本在故障中丢失
- 某些region的大部分副本在故障中丢失，而剩余的副本又没有收到最近的写入
-
造成数据丢失的原因
- sync-log 没有开启
- TiKV的lable没有正确设置
2.数据恢复流程
-
恢复数据前
要记录重要信息：集群版本、sync-log参数配置、宕机的TiKV数量和日志 等
找到超过一半副本在故障节点的region，并记录ID
数据恢复思路主要是：
更改 raft group configure，使剩余成员具有选举条件；
对所有region都丢失的情况，需要空region，来解决region is unavailable错误，使其仍可正常提供服务。 -
数据恢复流程
-
调整PD配置，关闭集群调度
- 有两种方式，通过命令，找到超过一半副本在故障节点的region，记录id
- 在上升故障的节点上，把上述region设置为 tombstone状态，以取消TiKV启动时对上述故障的检查tikv-ctl --db 使用的是本地模式，需要在TiKV shutdown前提下执行
在剩余正常节点上，移除上述region在故障节点的peer信息
至此，理论上仍然有副本健在的region，可以进行选举leader并提供服务
可以重启PD、重启TiKV集群、处理副本都丢失的region
再根据之前找到的region id ，创建空region，解决 region is unavailable错误
这样所有的region都可以提供服务。
后续使用API （curl http:// ），根据reigon id确认上述region属于那些表,对丢失数据进行处理
除了前述方法根据region id 找到丢失的表，
其实最有效的手段是 确定故障前几分钟 写入了哪些表，是否有ddl操作，是否可以重新消费更上游的数据重新写入。重导这部分数据，是最简单最完美的处理方式。否则只能对最重要的表和索引进行数据校验，保证集群的数据准确。
最后需要还原PD参数
