印刻数据库

外观

TiDB 故障诊断方法论 ​

故障诊断基本原则 ​

系统性原则 ​

故障诊断需从整体角度出发，综合考虑 TiDB 集群各组件（TiDB Server、TiKV、PD、TiFlash、TiCDC）的状态和相互影响，避免孤立分析单个组件。

数据驱动原则 ​

基于监控数据、日志信息和系统状态指标进行诊断，避免主观判断。重点关注 Prometheus 指标、组件日志和系统资源使用率。

分层诊断原则 ​

按照从应用层到存储层的顺序逐层排查：

  1. 应用层：业务 SQL 执行情况
  2. 计算层：TiDB Server 状态
  3. 调度层：PD 状态和 Region 分布
  4. 存储层：TiKV/TiFlash 状态
  5. 基础设施层：网络、磁盘、CPU 等

时效性原则 ​

故障发生后立即收集相关数据，避免数据丢失或被覆盖。特别是 TiDB 集群的日志和监控数据，应确保有足够的保留时间。

可重现原则 ​

对于间歇性故障，尝试通过复现步骤或模拟环境验证故障原因，确保诊断结果的准确性。

故障分类 ​

按照影响范围分类 ​

集群级故障 ​

影响整个 TiDB 集群的正常运行，导致所有业务无法访问。

  • PD 集群全部宕机
  • 网络分区导致集群分裂
  • 大规模 TiKV 节点故障

组件级故障 ​

影响单个或多个组件的功能，但集群仍可部分提供服务。

  • TiDB Server 节点宕机
  • 部分 TiKV 节点故障
  • TiFlash 同步异常
  • TiCDC 同步延迟

业务级故障 ​

仅影响特定业务或 SQL 查询，集群整体运行正常。

  • 慢查询导致业务超时
  • 热点问题影响写入性能
  • SQL 执行计划异常

按照故障类型分类 ​

性能类故障 ​

集群仍可运行，但性能下降导致业务受影响。

  • 查询延迟增加
  • 写入吞吐量下降
  • 资源使用率过高

可用性故障 ​

集群部分或全部不可用。

  • 节点宕机
  • 服务无响应
  • 数据不可访问

数据一致性故障 ​

数据出现不一致或丢失。

  • 事务提交失败
  • 读写数据不一致
  • 数据丢失

配置类故障 ​

错误的配置导致集群异常。

  • 参数配置错误
  • 拓扑结构不合理
  • 权限配置不当

诊断工具和方法 ​

监控工具 ​

Prometheus + Grafana ​

  • 核心作用：实时监控集群各项指标，提供可视化面板
  • 关键指标：
    • TiDB：QPS、TPS、查询延迟、连接数
    • TiKV：Region 健康状态、Raft 状态、存储使用率
    • PD：调度状态、Region 分布、Leader 分布
  • 使用方法：访问 Grafana 面板，查看对应组件的监控指标

TiUP Cluster Display ​

  • 核心作用：查看集群拓扑和节点状态
  • 使用命令：
    bash

tiup cluster display cluster-name


### 日志分析工具

#### TiDB 日志
- **默认路径**：`/tidb-deploy/tidb-port/logs/tidb.log`
- **关键信息**：SQL 执行日志、错误信息、慢查询日志
- **分析方法**：使用 `grep` 或专业日志分析工具过滤关键字

#### TiKV 日志
- **默认路径**：`/tidb-deploy/tikv-port/logs/tikv.log`
- **关键信息**：Raft 状态、Region 迁移、存储错误
- **分析方法**：关注 ERROR 和 WARNING 级别日志

#### PD 日志
- **默认路径**：`/tidb-deploy/pd-port/logs/pd.log`
- **关键信息**：调度决策、集群状态变化
- **分析方法**：跟踪调度相关日志

### 命令行工具

#### TiDB Dashboard
- **核心作用**：提供集群状态、慢查询、事务信息的综合视图
- **访问方式**：通过浏览器访问 `http://tidb-ip:tidb-port/dashboard`

#### pd-ctl
- **核心作用**：查看和管理 PD 集群
- **常用命令**：
```bash
pd-ctl -u http://<pd-ip>:<pd-port> store
pd-ctl -u http://<pd-ip>:<pd-port> region
pd-ctl -u http://<pd-ip>:<pd-port> scheduler

tikv-ctl ​

  • 核心作用：查看和管理 TiKV 节点
  • 常用命令：
    bash
    tikv-ctl --host <tikv-ip>:<tikv-port> status
tikv-ctl --host <tikv-ip>:<tikv-port> region --region-id <region-id>

tidb-ctl ​

  • 核心作用：查看和管理 TiDB 节点
  • 常用命令：
    bash
    tidb-ctl status --host <tidb-ip> --port <tidb-port>

系统工具 ​

网络诊断 ​

  • ping：检查网络连通性
  • traceroute：跟踪网络路径
  • telnet：检查端口可达性
  • iptables：检查防火墙规则

资源监控 ​

  • top/htop：实时查看 CPU、内存使用情况
  • iostat：查看磁盘 I/O 情况
  • df -h：查看磁盘空间使用率
  • netstat/ss：查看网络连接状态

故障诊断流程 ​

1. 故障感知与初步定位 ​

接收故障告警 ​

  • 监控系统告警（Prometheus Alertmanager）
  • 业务监控告警
  • 用户反馈

初步判断故障类型和影响范围 ​

  • 访问 TiDB Dashboard 查看集群整体状态
  • 运行 tiup cluster display cluster-name 检查节点状态
  • 查看 Prometheus 监控面板的关键指标

2. 数据收集 ​

收集监控数据 ​

  • 导出 Prometheus 相关指标数据
  • 保存 Grafana 面板截图

收集日志信息 ​

  • 收集各组件的错误日志和相关时间段的完整日志
  • 保存慢查询日志

收集系统状态 ​

  • 各节点的 CPU、内存、磁盘、网络使用率
  • 集群的 Region 分布情况
  • 事务执行状态

3. 深入分析与根因定位 ​

应用层分析 ​

  • 检查业务 SQL 执行情况
  • 分析慢查询日志
  • 查看 TiDB Dashboard 中的 Top SQL

计算层分析 ​

  • 检查 TiDB Server 连接数和线程数
  • 分析 TiDB Server 内存使用情况
  • 查看 TiDB Server 日志中的错误信息

调度层分析 ​

  • 检查 PD 集群状态和 Leader 选举情况
  • 分析 Region 分布和 Leader 分布
  • 查看 PD 调度日志和调度策略

存储层分析 ​

  • 检查 TiKV/TiFlash 节点状态
  • 分析 TiKV Region 健康状态
  • 查看 TiKV Raft 日志和存储错误

基础设施层分析 ​

  • 检查网络连通性和延迟
  • 分析磁盘 I/O 性能
  • 查看系统资源使用率

4. 故障修复与验证 ​

制定修复方案 ​

  • 根据根因分析结果制定修复方案
  • 评估修复方案的风险和影响
  • 准备回滚方案

执行修复操作 ​

  • 按照修复方案逐步执行
  • 实时监控修复过程中的系统状态
  • 如出现异常，立即执行回滚

验证修复效果 ​

  • 检查业务是否恢复正常
  • 监控系统指标是否回归正常范围
  • 验证相关功能是否正常工作

常见故障场景分析 ​

TiDB Server 高 CPU 使用率 ​

可能原因 ​

  • 慢查询或复杂查询过多
  • 连接数过高
  • 内部组件异常

诊断步骤 ​

  1. 查看 TiDB Dashboard 中的 Top SQL
  2. 检查连接数和线程数
  3. 分析 TiDB 日志中的慢查询
  4. 检查是否有异常的内部操作（如统计信息更新）

修复方案 ​

  • 优化或终止慢查询
  • 限制连接数
  • 调整 TiDB 配置参数

TiKV Region 大量 pending 状态 ​

可能原因 ​

  • PD 调度压力过大
  • TiKV 节点资源不足
  • 网络延迟过高

诊断步骤 ​

  1. 检查 PD 调度指标
  2. 分析 TiKV 节点资源使用率
  3. 查看网络延迟情况
  4. 检查 Region 分布是否均衡

修复方案 ​

  • 调整 PD 调度参数
  • 扩容 TiKV 节点
  • 优化网络环境
  • 均衡 Region 分布

PD Leader 频繁切换 ​

可能原因 ​

  • PD 节点资源不足
  • 网络不稳定
  • PD 配置不当

诊断步骤 ​

  1. 检查 PD 节点资源使用率
  2. 分析网络延迟和丢包情况
  3. 查看 PD 日志中的 Leader 选举记录
  4. 检查 PD 配置参数

修复方案 ​

  • 增加 PD 节点资源
  • 优化网络环境
  • 调整 PD 配置参数

故障诊断最佳实践 ​

建立完善的监控体系 ​

  • 配置全面的 Prometheus 监控指标
  • 设置合理的告警规则
  • 确保监控数据有足够的保留时间

定期进行故障演练 ​

  • 模拟各种故障场景
  • 验证故障处理流程的有效性
  • 提高团队的故障响应能力

建立故障知识库 ​

  • 记录每次故障的详情和处理过程
  • 总结常见故障的诊断方法和修复方案
  • 定期更新和分享知识库

优化日志和监控配置 ​

  • 调整日志级别，确保关键信息被记录
  • 增加重要指标的采样频率
  • 确保监控系统自身的高可用性

建立跨团队协作机制 ​

  • 与业务团队建立良好的沟通渠道
  • 与基础设施团队密切协作
  • 建立清晰的故障响应流程和责任分工

常见问题（FAQ） ​

Q1: 如何快速判断 TiDB 集群的健康状态？ ​

A1: 可以通过以下方式快速判断：

  • 运行 tiup cluster display cluster-name 查看节点状态
  • 访问 TiDB Dashboard 查看集群概览
  • 检查 Prometheus 监控面板中的关键指标
  • 执行简单的 SQL 查询验证集群可用性

Q2: 遇到 TiDB 慢查询问题，应该从哪些方面入手分析？ ​

A2: 可以从以下几个方面分析：

  • 查看 TiDB Dashboard 中的 Top SQL，分析执行计划
  • 检查 SQL 语句是否合理，是否缺少索引
  • 分析表结构和数据分布
  • 检查 TiKV 节点是否存在热点问题
  • 查看 TiDB Server 和 TiKV 节点的资源使用情况

Q3: 如何处理 TiKV 节点故障？ ​

A3: 处理流程如下：

  1. 确认节点故障情况，检查是否可以恢复
  2. 如果节点无法恢复，使用 tiup cluster scale-in 移除故障节点
  3. 使用 tiup cluster scale-out 添加新节点
  4. 等待 PD 重新调度 Region，恢复集群平衡
  5. 验证集群状态和数据完整性

Q4: PD 调度缓慢应该如何优化？ ​

A4: 可以从以下几个方面优化：

  • 调整 PD 调度参数，如 max-snapshot-count、max-pending-peer-count
  • 增加 PD 节点资源
  • 优化网络环境，降低网络延迟
  • 检查 TiKV 节点资源使用情况，确保有足够的资源处理调度任务
  • 分析 Region 分布，避免热点问题

Q5: 如何避免 TiDB 集群的常见故障？ ​

A5: 可以采取以下措施：

  • 建立完善的监控和告警体系
  • 定期进行集群健康检查
  • 遵循最佳实践进行集群配置和管理
  • 定期进行故障演练
  • 及时更新 TiDB 版本，修复已知漏洞
  • 建立健全的故障处理流程和知识库