课程名称：课程版本（101/201/301）+ 3.9.4 Mutil Site Disaster Recovery（TiDB 跨数据中心部署方案）
学习时长：
15分钟
课程收获：
在多副本异常情况下，保障集群正常可用
课程内容：
一、Serveral situations in which data loss occurs
- 首先了解什么情况会出现丢失
- 某些Region全部副本丢失
- 某些Region大部分副本在故障中丢失，而剩余的副本未收到最近的写入
- 哪些场景容易触发上述情况出现
- sync-log参数未开启
- TiKV的lable没有正确的设置
二、Before you start data recovery
- 保持一些重要数据
- 集群的版本、Sync-log的配置
- 异常宕机的TiKV数量及日志等
- 找到超过一半副本在故障节点中的Region，并记录他们的ID
- 恢复思路
- 更改raft-group-config，是剩余成员具有选举权
- 对于所有region都丢失的情况，需要创建空Region解决Region Unavailable错误
，使其仍可正常提供服务
三、Data recovery steps（Region大部分副本丢失，但仍然有副本健在时）
- 为了在恢复过程中将异常情况降到最低，建议调整PD配置，关闭集群调度
- 按照如下方式找到超过一半在故障节点上的region并记录ID
- 在发生故障的节点上把上述找到的region的状态设置为tombstone状态，去将TiKV节点启动时对这些Region检查
- 注意：使用tikv-ctl --db时，代表TiKV-CTL管理工具使用的是本地模式，此模式需要运行在TiKV节点shutdown模式下
- 在剩余正常节点上移除上述region在故障节点上的PRCC，视region数量我们提供了-r和–al两种模式简化操作
- 截止到此，理论上仍有健在副本的region都可以正常选举出leader并提供服务，这时可以重启PD和TiKV集群处理无副本的region
- 使用pd-ctl检查无leader的region，PD需启动
- 根据上面找到的Region ID使用tikv-ctl创建空Region解决Unavailable错误
- 根据Region ID确认Region属于哪个表或索引并处理
- PD、TiDB和TiKV需启动
- 在实践中，更有效的手段是询问用户在掉电前的某一段时间内，比如5分钟，大概写入了哪些表、是否有DDL操作、是否可以重新消费上游数据来再次写入，如果可以重导这部分数据，则是最简单最完美的恢复方式，否则只能对重要的表和索引进行数据校验，保证集群中存在的数据是准确无误的。
- 恢复PD配置，开启集群调度
- 完成以上恢复步骤后，所有TiKV是可以正常启动且数据库集群是没有报Region Unavailable错误