TiDB 集群中单个 TiKV 节点宕机通常不会导致 Region 不可用，因为 Raft 协议多数派副本仍可提供服务。若多数派副本丢失导致 Region unavailable，需尽快恢复节点或剔除故障 Store 触发 PD 调度补副本。

命令速用版

以下命令用于快速查看集群状态和 Store 信息，需在部署机器或具备权限的控制节点执行。

tiup cluster display <cluster-name>
pd-ctl -u http://<pd-ip>:<pd-port> store
pd-ctl -u http://<pd-ip>:<pd-port> region check miss-peer

为什么会这样

TiDB 使用 Raft 共识协议保证数据一致性，Region 数据多副本存储，默认副本数为 3。

当 TiKV 节点宕机时，若剩余存活副本数满足多数派（如 3 副本中存活 2 个），Raft 组仍可选举 Leader 提供服务。若存活副本数不足多数派，Region 将进入 unavailable 状态，直到副本补齐或节点恢复。

分步处理

按以下顺序操作，避免误删数据或加剧集群负载。

步骤 1：确认故障节点状态

使用 tiup 查看集群状态，确认 TiKV 节点是 Down 还是 Unreachable。

tiup cluster display <cluster-name>

步骤 2：尝试恢复节点

若为进程崩溃或机器重启，优先尝试启动 TiKV 服务。若机器硬件故障，跳过此步。

tiup cluster start <cluster-name> -R tikv

步骤 3：剔除故障 Store（若节点无法恢复）

确认节点无法短期恢复后，使用 scale-in 命令剔除 Store，PD 会自动调度新副本。

tiup cluster scale-in <cluster-name> -N <node-ip>:<port>

步骤 4：监控调度进度

观察 PD 监控面板，等待 Region 副本数恢复至配置值。

怎么验证是否生效

通过 PD 控制工具检查是否有异常 Region，同时观察业务延迟是否回落。

pd-ctl -u http://<pd-ip>:<pd-port> region check miss-peer
pd-ctl -u http://<pd-ip>:<pd-port> region check extra-peer

若命令无输出或输出为空，表示副本健康。同时检查 Grafana 中 TiKV 状态面板，确认 No Leader 区域归零。

常见坑

• 网络抖动误判：节点短暂网络分区可能被标记为 Down，建议观察几分钟再执行 scale-in。
• 磁盘空间不足：若因磁盘满导致 TiKV 宕机，恢复前需清理空间，否则启动后再次崩溃。
• 强制删除 Store：未确认数据同步状态前强制删除 Store 可能导致数据丢失，优先使用 tiup scale-in 流程。

常见问题

TiKV 节点宕机后数据会丢失吗？

默认 3 副本配置下，单个节点宕机不会丢失数据，Raft 协议保证多数派写入成功。

Region unavailable 状态会持续多久？

取决于故障节点恢复速度或 PD 调度新副本的速度，公开资料中没有看到可靠的量化数据，通常与数据量和网络带宽有关。

可以直接 kill 掉 TiKV 进程吗？

不建议直接 kill，会导致 PD 标记节点为 Down 并触发调度，增加集群负载，应通过 tiup 命令操作。

参考来源

• PingCAP 官方文档，TiDB 架构概览，https://docs.pingcap.com/zh/tidb/stable/architecture
• PingCAP 官方文档，TiKV 运维指南，https://docs.pingcap.com/zh/tidb/stable/tikv-control