在实际生产环境中，TiDB 集群是可能会出现丢失数据情况，如：

• 一个 TiDB 集群可能会出现多台 TiKV 机器短时间内接连故障且无法短期内恢复
• 一个双机房部署的 TiDB 集群的其中一个机房整体故障等

在上述这些情形下，会出现部分 Region 的多个副本（包含全部副本的情况）同时故障，进而导致 Region 的数据部分或全部丢失的问题。 这个时候，最重要的是快速地最大程度地恢复数据并恢复 TiDB 集群正常服务。

副本数据恢复包含两个部分：故障 Region 处理和丢失数据处理

• 故障 Region 处理，针对 Region 数据丢失的严重情况，可分为两种：
  • Region 至少还有 1 个副本，恢复思路是在 Region 的剩余副本上移除掉所有位于故障节点上的 Peer， 这样可以用这些剩余副本来重新选举和补充副本来恢复，但这些剩余副本中可能不包含最新的 Raft Log 更新，这个时候就会丢失部分数据
  • Region 的所有副本都丢失了，这个 Region 的数据就丢失了，无法恢复。 可以通过创建 1 个空 Region 来解决 Region 不可用的问题
• 丢失数据处理
  • 根据故障 Region ID 找到对应的表，找到相关用户并询问用户在故障前的某一段时间内（比如 5 min），大概写入了哪些数据表，是否有 DDL 操作，是否可以重新消费更上游的数据来再次写入，等等
  • 如果可以重导，则是最简单的处理方式。否则的话，则只能对重要的数据表，检查数据索引的一致性 ，保证还在的数据是正确无误的

• 处理前后的 PD 调度处理

  • 为将恢复过程中可能的异常情况降到最少，需在故障处理期间禁用相关的调度：
    • 通过 获取 region-schedule-limit、replica-schedule-limit、leader-schedule-limit、merge-schedule-limit 这 4 个参数的值，并记录下来用于后面恢复设置
    • 通过 将这 4 个参数设为 0
    • 处理完之后需要将这 4 个参数进行恢复

• 处理所有副本都丢失的 Region

  • 重启 PD，重启 TiKV 集群，使用 检查没有 Leader 的 Region：

  • 创建空 Region 解决 Unavailable 报错。任选一个 Store，关闭上面的 TiKV，然后执行：