印刻数据库

外观

TiDB TiKV 服务器故障处理 ​

故障识别 ​

1. 监控告警 ​

通过监控系统（如 Prometheus + Grafana）识别 TiKV 故障：

  • 节点状态告警：TiKV 节点离线或状态异常
  • Raft 状态告警：Raft 日志复制延迟过高
  • 存储告警：磁盘空间不足、磁盘 I/O 过高
  • 性能告警：请求延迟过高、QPS 下降
  • 网络告警：网络延迟过高、丢包率增加

2. 集群状态检查 ​

bash
# 检查集群状态
tiup cluster display <cluster-name>

# 检查 TiKV 节点状态
tiup ctl tikv --host <tikv-host>:20160 store

# 检查 PD 中的 TiKV 状态
tiup ctl pd --host <pd-host>:2379 store

3. 日志分析 ​

检查 TiKV 节点日志，识别故障信息：

bash
tail -f /path/to/tikv/log/tikv.log | grep -i error

常见故障类型及处理 ​

1. TiKV 节点宕机 ​

故障现象 ​

  • 集群状态显示 TiKV 节点离线
  • 相关告警触发
  • 部分 Region 变为不可用或只读状态

处理步骤 ​

  1. 确认宕机原因

    • 检查服务器硬件状态
    • 检查操作系统日志
    • 检查 TiKV 日志

  2. 尝试重启节点

    bash
    tiup cluster start <cluster-name> -R tikv -N <tikv-host>:20160

  3. 等待节点恢复

    • 节点重启后，会自动加入集群
    • Raft 会自动同步数据
    • 监控 Region 状态，确保所有 Region 恢复正常

  4. 如果无法重启

    • 从集群中移除故障节点
    bash
    tiup cluster scale-in <cluster-name> -N <tikv-host>:20160
    • 添加新节点替换故障节点
    bash
    tiup cluster scale-out <cluster-name> scale-out.yaml

2. 网络故障 ​

故障现象 ​

  • TiKV 节点与其他节点无法通信
  • Raft 日志复制延迟增加
  • Region 状态异常

处理步骤 ​

  1. 检查网络连接

    bash
    ping <other-node-ip>
traceroute <other-node-ip>

  2. 检查防火墙设置

    • 确保 TiKV 端口（默认 20160）开放
    • 检查网络 ACL 规则

  3. 检查网络设备

    • 检查交换机、路由器状态
    • 检查网络线缆连接

  4. 重启网络服务

    bash
    # 重启网络服务（根据操作系统）
systemctl restart network # CentOS/RHEL
systemctl restart networking # Ubuntu/Debian

  5. 等待网络恢复

    • 网络恢复后，Raft 会自动同步数据
    • 监控 Region 状态，确保所有 Region 恢复正常

3. 磁盘故障 ​

故障现象 ​

  • 磁盘 I/O 错误
  • 数据写入失败
  • TiKV 节点崩溃
  • 磁盘空间不足告警

处理步骤 ​

  1. 检查磁盘状态

    bash
    # 检查磁盘空间
df -h

# 检查磁盘健康状态
smartctl -a /dev/sda

# 检查文件系统
fsck -n /dev/sda1

  2. 磁盘空间不足处理

    • 清理日志文件
    • 清理临时文件
    • 考虑扩容磁盘
    • 调整 TiKV 配置，限制日志大小

  3. 磁盘损坏处理

    • 从集群中移除故障节点
    bash
    tiup cluster scale-in <cluster-name> -N <tikv-host>:20160
    • 更换故障磁盘
    • 重新部署 TiKV 节点
    bash
    tiup cluster scale-out <cluster-name> scale-out.yaml

4. 内存不足 ​

故障现象 ​

  • 系统 OOM killer 杀死 TiKV 进程
  • TiKV 节点频繁重启
  • 内存使用率接近 100%

处理步骤 ​

  1. 检查内存使用情况

    bash
    free -h
top

  2. 分析内存占用原因

    • 检查 TiKV 配置中的内存相关参数
    • 检查是否有内存泄漏
    • 检查是否有其他进程占用大量内存

  3. 调整 TiKV 内存配置

    toml
    # 调整 TiKV 内存配置
[storage]
block-cache-size = "8GB" # 根据实际情况调整

[raft-store]
raft-log-cache-size = "512MB" # 根据实际情况调整

  4. 优化系统内存设置

    • 调整 swap 配置
    • 调整 OOM killer 策略
    • 考虑增加物理内存

  5. 重启 TiKV 节点

    bash
    tiup cluster restart <cluster-name> -R tikv -N <tikv-host>:20160

5. CPU 使用率过高 ​

故障现象 ​

  • CPU 使用率接近 100%
  • TiKV 响应延迟增加
  • 集群性能下降

处理步骤 ​

  1. 检查 CPU 使用情况

    bash
    top
mpstat -P ALL 1

  2. 分析 CPU 占用原因

    • 检查是否有大量查询请求
    • 检查是否有后台任务（如 Compaction）
    • 检查是否有性能瓶颈

  3. 优化 TiKV 配置

    toml
    # 调整 Compaction 线程数
[rocksdb]
max-background-jobs = 8 # 根据 CPU 核心数调整
max-background-compactions = 4 # 根据 CPU 核心数调整

  4. 优化查询

    • 分析慢查询日志
    • 优化索引
    • 调整查询语句

  5. 考虑扩容

    • 增加 TiKV 节点数量
    • 均衡数据分布

6. Raft 状态异常 ​

故障现象 ​

  • Raft 日志复制延迟过高
  • Region 不可用
  • Leader 频繁切换
  • Raft 选举超时

处理步骤 ​

  1. 检查 Raft 状态

    bash
    # 检查 Region 状态
tiup ctl tikv --host <tikv-host>:20160 region --region-id <region-id>

# 检查 Raft 状态
tiup ctl tikv --host <tikv-host>:20160 raft --region-id <region-id>

  2. 分析 Raft 异常原因

    • 网络延迟过高
    • 节点负载过高
    • 磁盘 I/O 过高
    • Raft 配置不合理

  3. 调整 Raft 配置

    toml
    [raft-store]
raft-base-tick-interval = "1s" # 调整 Raft tick 间隔
raft-election-timeout-ticks = 10 # 调整选举超时时间
raft-max-inflight-msgs = 256 # 调整最大 inflight 消息数

  4. 优化节点性能

    • 调整资源分配
    • 优化磁盘 I/O
    • 优化网络连接

  5. 手动干预 Raft 状态

    bash
    # 强制转移 Leader
tiup ctl tikv --host <tikv-host>:20160 transfer-leader --region-id <region-id> --to-store <store-id>

7. 数据损坏 ​

故障现象 ​

  • TiKV 启动失败，提示数据损坏
  • 查询时返回数据损坏错误
  • 校验和不匹配

处理步骤 ​

  1. 确认数据损坏范围

    • 检查 TiKV 日志，定位损坏的 Region
    • 检查数据文件完整性

  2. 从集群中移除故障节点

    bash
    tiup cluster scale-in <cluster-name> -N <tikv-host>:20160

  3. 恢复数据

    • 从备份恢复数据
    • 或等待 Raft 从其他节点同步完整数据

  4. 重新部署 TiKV 节点

    bash
    tiup cluster scale-out <cluster-name> scale-out.yaml

  5. 验证数据完整性

    bash
    # 执行数据一致性检查
tiup ctl tikv --host <tikv-host>:20160 checksum --region-id <region-id>

TiKV 故障处理最佳实践 ​

1. 监控与告警 ​

  • 建立完善的监控体系，覆盖 TiKV 所有关键指标
  • 设置合理的告警阈值
  • 配置告警通知（邮件、短信、即时通讯工具）
  • 定期检查监控数据，发现潜在问题

2. 定期维护 ​

  • 定期检查硬件状态（磁盘、内存、CPU）
  • 定期清理日志和临时文件
  • 定期备份数据
  • 定期更新系统和软件

3. 容量规划 ​

  • 提前规划存储容量
  • 监控磁盘使用率，及时扩容
  • 考虑数据增长趋势
  • 合理配置 TiKV 节点数量

4. 高可用设计 ​

  • 部署足够数量的 TiKV 节点（至少 3 个）
  • 确保 TiKV 节点分布在不同的机架或可用区
  • 配置合理的副本数（默认 3 副本）
  • 实现跨数据中心部署

5. 故障演练 ​

  • 定期进行故障演练
  • 模拟各种故障场景，测试故障处理流程
  • 优化故障处理流程
  • 提高团队故障处理能力

故障处理流程 ​

1. 故障发现 ​

  • 通过监控告警发现故障
  • 通过业务反馈发现故障
  • 定期巡检发现故障

2. 故障定位 ​

  • 收集故障信息
  • 分析日志和监控数据
  • 定位故障原因和范围

3. 故障处理 ​

  • 根据故障类型执行相应的处理步骤
  • 实施临时解决方案
  • 监控处理效果

4. 故障恢复 ​

  • 验证故障是否完全恢复
  • 检查数据一致性
  • 恢复业务流量

常见问题（FAQ） ​

Q1: TiKV 节点宕机后，集群需要多长时间恢复？ ​

A1: TiKV 节点宕机后，集群恢复时间取决于：

  • 宕机节点上的 Region 数量
  • 每个 Region 的数据量
  • 网络带宽
  • 其他 TiKV 节点的负载

通常情况下，如果集群配置合理，小集群（10 个以内 TiKV 节点）可以在几分钟内恢复，大集群可能需要更长时间。

Q2: TiKV 节点磁盘空间不足怎么办？ ​

A2: TiKV 节点磁盘空间不足时，可以采取以下措施：

  • 清理无用的日志文件
  • 调整 TiKV 配置，限制日志大小
  • 扩容磁盘
  • 增加 TiKV 节点数量，均衡数据分布

Q3: 如何避免 TiKV 节点内存不足？ ​

A3: 避免 TiKV 节点内存不足的措施包括：

  • 根据服务器内存大小合理配置 TiKV 内存参数
  • 监控内存使用率，及时扩容
  • 优化查询，减少内存占用
  • 定期重启 TiKV 节点（在业务低峰期）

Q4: TiKV 节点 Raft 复制延迟过高怎么办？ ​

A4: 处理 TiKV 节点 Raft 复制延迟过高的措施包括：

  • 检查网络连接，确保低延迟
  • 优化磁盘 I/O，提高写入性能
  • 调整 Raft 配置参数
  • 均衡 TiKV 节点负载

Q5: 如何验证 TiKV 节点数据完整性？ ​

A5: 验证 TiKV 节点数据完整性的方法包括：

  • 使用 tiup ctl tikv checksum 命令检查 Region 校验和
  • 执行数据一致性检查
  • 从备份恢复数据并与原数据对比
  • 运行业务查询，验证数据正确性

Q6: TiKV 节点故障后，如何确保数据不丢失？ ​

A6: TiKV 基于 Raft 共识算法，默认配置 3 副本，只要有超过半数的副本可用，数据就不会丢失。为确保数据安全：

  • 配置合理的副本数（建议至少 3 副本）
  • 确保副本分布在不同的机架或可用区
  • 定期备份数据
  • 监控副本状态，及时处理副本丢失问题

Q7: 如何处理 TiKV 节点频繁崩溃？ ​

A7: 处理 TiKV 节点频繁崩溃的步骤：

  • 分析崩溃日志，定位根本原因
  • 检查硬件状态，特别是磁盘和内存
  • 检查操作系统日志，看是否有系统级错误
  • 调整 TiKV 配置，优化资源使用
  • 考虑更换故障硬件
  • 升级 TiKV 版本，修复已知 bug

Q8: 如何手动转移 TiKV Region Leader？ ​

A8: 可以使用以下命令手动转移 TiKV Region Leader：

bash
tiup ctl tikv --host <tikv-host>:20160 transfer-leader --region-id <region-id> --to-store <store-id>

这可以用于均衡 TiKV 节点负载，或在节点维护前提前转移 Leader。