印刻数据库

外观

TiDB 存储故障处理 ​

TiDB 的存储层主要由 TiKV 组件负责，存储故障是 TiDB 集群中常见的故障类型之一。存储故障包括磁盘故障、存储节点故障、数据损坏等，这些故障可能导致数据丢失或集群不可用。本章将介绍 TiDB 存储故障的类型、现象、原因和解决方案。

存储故障类型 ​

1. 磁盘故障 ​

磁盘故障是指 TiKV 节点的磁盘出现问题，无法正常读写数据。

现象 ​

  • TiKV 节点日志中出现大量 I/O 错误
  • 磁盘使用率异常高或显示为 100%
  • 磁盘读写速度显著下降
  • TiKV 节点状态变为不可用
  • 监控中显示磁盘相关指标异常

原因 ​

  • 磁盘物理损坏
  • 磁盘空间不足
  • 文件系统错误
  • 磁盘控制器故障
  • 电源故障导致磁盘损坏

解决方案 ​

  • 紧急处理：如果是单盘故障，且 TiKV 节点有多个磁盘，可以将故障磁盘上的数据迁移到其他磁盘
  • 节点替换：如果是节点级别的磁盘故障，需要替换整个 TiKV 节点
  • 数据恢复：如果磁盘故障导致数据丢失，需要使用备份数据进行恢复
  • 监控告警：配置磁盘空间和 I/O 告警，提前发现磁盘故障
  • 定期检查：定期检查磁盘健康状态，使用工具如 smartctl 检测磁盘坏道

2. TiKV 节点故障 ​

TiKV 节点故障是指 TiKV 进程或节点本身出现问题，无法正常提供服务。

现象 ​

  • TiKV 进程崩溃或无法启动
  • PD 监控中显示 TiKV 节点状态为 down
  • 集群中 Region Leader 分布异常
  • 读写请求延迟增加

原因 ​

  • 硬件故障（CPU、内存、磁盘、网络等）
  • 软件 bug 导致进程崩溃
  • 配置错误导致进程无法启动
  • 资源不足（CPU、内存、磁盘空间等）
  • 网络分区导致节点隔离

解决方案 ​

  • 重启节点：尝试重启 TiKV 节点，观察是否能够恢复
  • 检查日志：查看 TiKV 日志，确定故障原因
  • 替换硬件：如果是硬件故障，更换故障硬件
  • 修复配置：如果是配置错误，修复配置后重启节点
  • 增加资源：如果是资源不足，增加节点资源或添加新节点
  • 等待自动恢复：TiDB 会自动检测和恢复 TiKV 节点故障，包括重新选举 Region Leader 和复制数据副本

3. 数据损坏 ​

数据损坏是指存储在 TiKV 中的数据出现错误或不一致。

现象 ​

  • 查询返回错误的数据
  • TiKV 日志中出现数据校验错误
  • Region 状态变为不健康
  • 数据恢复失败
  • 集群性能下降

原因 ​

  • 磁盘坏道导致数据写入错误
  • 内存故障导致数据缓存错误
  • 网络传输错误导致数据损坏
  • 软件 bug 导致数据写入错误
  • 恶意攻击或误操作导致数据损坏

解决方案 ​

  • 数据校验：使用 TiKV 提供的数据校验工具检查数据完整性
  • 数据恢复：使用备份数据恢复损坏的数据
  • Region 修复：使用 PD 工具修复不健康的 Region
  • 节点替换：如果数据损坏严重，替换整个 TiKV 节点
  • 配置优化：调整 TiKV 配置，如启用数据校验、增加副本数量等

存储故障诊断 ​

1. 故障定位 ​

查看 TiKV 日志 ​

TiKV 日志是诊断存储故障的重要依据，可以通过以下命令查看 TiKV 日志：

bash
# 查看最近的 TiKV 日志
tail -n 1000 /tidb-deploy/tikv-20160/log/tikv.log

# 搜索错误信息
grep -i error /tidb-deploy/tikv-20160/log/tikv.log

# 搜索磁盘相关错误
grep -i disk /tidb-deploy/tikv-20160/log/tikv.log
grep -i io /tidb-deploy/tikv-20160/log/tikv.log

查看监控指标 ​

通过 Prometheus 和 Grafana 查看 TiKV 相关的监控指标，如：

  • 磁盘使用率：node_filesystem_avail_bytes
  • 磁盘 I/O 延迟：node_disk_io_time_seconds_total
  • TiKV 状态：tikv_store_status
  • Region 健康状态：tikv_raftstore_region_healthy
  • 数据校验错误：tikv_storage_checksum_error_total

使用 TiKV 诊断工具 ​

TiKV 提供了一些诊断工具，可以帮助定位存储故障：

bash
# 查看 TiKV 状态
tikv-ctl status --host=<tikv-host>:20160

# 查看 Region 信息
tikv-ctl region --host=<tikv-host>:20160 --region-id=<region-id>

# 检查数据完整性
tikv-ctl checksum --host=<tikv-host>:20160 --region-id=<region-id>

2. 故障分类 ​

根据故障的严重程度和影响范围，可以将存储故障分为以下几类：

  • 轻度故障：单个磁盘故障，不影响整个节点的运行
  • 中度故障：单个 TiKV 节点故障，影响部分数据的访问
  • 重度故障：多个 TiKV 节点故障，可能导致数据丢失或集群不可用
  • 灾难性故障：整个存储层故障，导致集群完全不可用

存储故障处理流程 ​

1. 磁盘故障处理流程 ​

单盘故障处理 ​

  1. 确认故障：通过监控和日志确认磁盘故障
  2. 隔离故障：将故障磁盘从 TiKV 配置中移除，或停止使用故障磁盘
  3. 数据迁移：将故障磁盘上的数据迁移到其他健康磁盘
  4. 修复或替换：修复或替换故障磁盘
  5. 恢复配置：将修复后的磁盘重新添加到 TiKV 配置中
  6. 验证恢复：验证数据完整性和服务可用性

节点级磁盘故障处理 ​

  1. 确认故障：通过监控和日志确认节点磁盘故障
  2. 标记节点不可用：在 PD 中将故障节点标记为不可用
  3. 添加新节点：添加新的 TiKV 节点到集群中
  4. 数据迁移：PD 自动将故障节点上的数据迁移到新节点
  5. 移除故障节点：从集群中移除故障节点
  6. 验证恢复：验证数据完整性和服务可用性

2. TiKV 节点故障处理流程 ​

节点进程崩溃处理 ​

  1. 确认故障：通过监控和日志确认 TiKV 进程崩溃
  2. 尝试重启：尝试重启 TiKV 进程
  3. 检查日志：查看 TiKV 日志，确定崩溃原因
  4. 修复问题：根据日志信息修复问题，如调整配置、修复硬件故障等
  5. 验证恢复：验证 TiKV 进程是否正常运行，数据是否完整

节点完全不可用处理 ​

  1. 确认故障：通过监控和日志确认节点完全不可用
  2. 等待自动恢复：等待 PD 自动检测到节点故障，并开始数据迁移
  3. 添加新节点：如果需要，添加新的 TiKV 节点到集群中
  4. 监控数据迁移：监控数据迁移进度，确保数据迁移完成
  5. 移除故障节点：从集群中移除故障节点
  6. 验证恢复：验证数据完整性和服务可用性

3. 数据损坏处理流程 ​

  1. 确认数据损坏：通过查询错误或日志确认数据损坏
  2. 定位损坏范围：确定数据损坏的具体范围，如哪个 Region 或表
  3. 隔离损坏数据：将损坏的数据隔离，避免影响其他数据
  4. 数据恢复：使用备份数据恢复损坏的数据
  5. 验证恢复：验证恢复后的数据完整性
  6. 分析原因：分析数据损坏的原因，采取措施防止类似问题再次发生

存储故障恢复工具 ​

1. BR（Backup & Restore） ​

BR 是 TiDB 的备份恢复工具，可以用于恢复损坏的数据。

备份数据恢复 ​

bash
# 使用 BR 恢复全量备份
tiup br restore full \
  --pd="<pd-host>:2379" \
  --storage="s3://<bucket-name>/backup/full" \
  --ratelimit=128 \
  --concurrency=64

# 使用 BR 恢复指定表
tiup br restore table \
  --pd="<pd-host>:2379" \
  --storage="s3://<bucket-name>/backup/table" \
  --table="`db_name.table_name`" \
  --ratelimit=128 \
  --concurrency=64

2. TiKV 数据修复工具 ​

TiKV 提供了一些数据修复工具，可以用于修复损坏的数据。

使用 tikv-ctl 修复数据 ​

bash
# 检查 Region 数据完整性
tikv-ctl checksum --host=<tikv-host>:20160 --region-id=<region-id>

# 修复 Region 数据
tikv-ctl repair --host=<tikv-host>:20160 --region-id=<region-id>

3. PD 调度工具 ​

PD 提供了调度工具，可以用于调整 Region 分布和副本数量。

调整 Region 副本数量 ​

bash
# 使用 pd-ctl 调整集群默认副本数量
pd-ctl -u http://<pd-host>:2379 config set max-replicas 3

# 使用 pd-ctl 调整单个 Region 副本数量
pd-ctl -u http://<pd-host>:2379 operator add add-peer <region-id> <store-id>

存储故障预防措施 ​

1. 硬件层面预防 ​

  • 使用高质量硬件：选择可靠性高的服务器和磁盘
  • 冗余设计：采用 RAID 等冗余技术，提高磁盘可靠性
  • 多磁盘配置：每个 TiKV 节点配置多个磁盘，分散风险
  • 热备份：配置热备份磁盘，便于快速替换故障磁盘

2. 软件层面预防 ​

  • 合理配置：调整 TiKV 配置，如 storage.block-cache.capacity、raftstore.apply-pool-size 等
  • 定期备份：制定定期备份策略，确保数据安全
  • 监控告警：配置全面的监控和告警，提前发现潜在问题
  • 定期检查：定期检查 TiKV 节点和磁盘的健康状态
  • 版本更新：及时更新 TiDB 版本，修复已知 bug

3. 运维层面预防 ​

  • 制定应急预案：制定详细的存储故障应急预案
  • 定期演练：定期进行存储故障演练，提高故障处理能力
  • 培训人员：培训运维人员，提高存储故障处理技能
  • 文档完善：完善存储故障处理文档，便于快速参考

存储故障案例分析 ​

1. 磁盘空间不足案例 ​

背景 ​

某公司的 TiDB 集群中，一个 TiKV 节点的磁盘空间不足，导致 TiKV 进程崩溃。

现象 ​

  • TiKV 日志中出现 "No space left on device" 错误
  • 磁盘使用率显示为 100%
  • TiKV 进程崩溃，无法重启

处理过程 ​

  1. 紧急处理：删除节点上不必要的日志文件和临时文件，释放部分磁盘空间
  2. 重启节点：重启 TiKV 进程
  3. 扩容处理：添加新的 TiKV 节点到集群中
  4. 数据迁移：PD 自动将故障节点上的数据迁移到新节点
  5. 调整配置：调整 TiKV 配置，增加磁盘空间告警阈值
  6. 优化清理策略：优化日志和临时文件的清理策略

结果 ​

  • TiKV 节点成功恢复
  • 集群数据完整无损
  • 业务服务恢复正常
  • 制定了更完善的磁盘空间监控和清理策略

2. TiKV 节点硬件故障案例 ​

背景 ​

某公司的 TiDB 集群中，一个 TiKV 节点的内存出现故障，导致 TiKV 进程频繁崩溃。

现象 ​

  • TiKV 进程频繁崩溃
  • 日志中出现内存相关错误
  • 系统日志中出现硬件错误信息

处理过程 ​

  1. 确认故障：通过日志确认节点硬件故障
  2. 标记节点不可用：在 PD 中将故障节点标记为不可用
  3. 添加新节点：添加新的 TiKV 节点到集群中
  4. 数据迁移：PD 自动将故障节点上的数据迁移到新节点
  5. 替换硬件：替换故障节点的内存
  6. 验证恢复：验证数据完整性和服务可用性

结果 ​

  • 故障节点成功替换
  • 集群数据完整无损
  • 业务服务恢复正常
  • 制定了更完善的硬件监控和故障处理流程

3. 数据损坏案例 ​

背景 ​

某公司的 TiDB 集群中，由于磁盘坏道导致部分数据损坏。

现象 ​

  • 查询时返回 "Data corruption" 错误
  • TiKV 日志中出现数据校验错误
  • 部分 Region 状态变为不健康

处理过程 ​

  1. 确认数据损坏：通过查询错误和日志确认数据损坏
  2. 定位损坏范围：确定损坏的数据范围
  3. 使用备份恢复：使用 BR 工具从备份中恢复损坏的数据
  4. 验证恢复：验证恢复后的数据完整性
  5. 替换故障磁盘：替换出现坏道的磁盘
  6. 优化监控：增加数据完整性监控，提前发现数据损坏

结果 ​

  • 损坏的数据成功恢复
  • 集群服务恢复正常
  • 故障磁盘被替换
  • 增强了数据完整性监控

存储故障最佳实践 ​

1. 监控与告警最佳实践 ​

  • 全面监控：监控磁盘空间、I/O 性能、TiKV 状态等指标
  • 分层告警：根据故障严重程度设置不同级别的告警
  • 告警触发条件：设置合理的告警触发条件，避免误告警
  • 告警通知方式：根据告警级别选择合适的通知方式
  • 告警处理流程：制定明确的告警处理流程，确保及时响应

2. 备份与恢复最佳实践 ​

  • 定期备份：制定定期备份策略，包括全量备份和增量备份
  • 多副本备份：将备份数据存储在多个地理位置，提高数据安全性
  • 备份验证：定期验证备份数据的完整性和可恢复性
  • 恢复演练：定期进行恢复演练，确保恢复流程可行
  • 备份自动化：使用自动化工具进行备份，减少人为错误

3. 故障处理最佳实践 ​

  • 快速响应：收到告警后，立即响应并开始处理
  • 准确定位：通过监控和日志准确定位故障原因
  • 优先恢复服务：在保证数据安全的前提下，优先恢复业务服务
  • 完整记录：详细记录故障处理过程，便于后续分析
  • 总结改进：故障处理完成后，总结经验教训，改进故障处理流程

常见问题（FAQ） ​

Q1: TiKV 节点磁盘空间不足时，如何紧急处理？ ​

A1: 可以采取以下紧急处理措施：

  • 删除不必要的日志文件和临时文件
  • 调整 TiKV 日志级别，减少日志输出
  • 临时增加磁盘空间，如挂载临时磁盘
  • 迁移部分数据到其他节点

Q2: TiKV 节点故障后，数据会丢失吗？ ​

A2: 正常情况下，TiKV 节点故障不会导致数据丢失，因为 TiDB 采用多副本存储机制，每个 Region 有多个副本分布在不同的节点上。当一个节点故障时，PD 会自动调度新的副本，确保数据可用性。

Q3: 如何查看 TiKV 节点的磁盘使用情况？ ​

A3: 可以使用以下方法查看 TiKV 节点的磁盘使用情况：

  • 使用 df -h 命令查看磁盘使用率
  • 通过 Grafana 监控面板查看磁盘使用率指标
  • 使用 TiDB Dashboard 的节点监控页面查看

Q4: 如何防止 TiKV 数据损坏？ ​

A4: 防止 TiKV 数据损坏的方法包括：

  • 使用高质量的硬件设备
  • 配置合理的 TiKV 参数
  • 启用数据校验功能
  • 定期备份数据
  • 监控数据完整性
  • 及时更新 TiDB 版本

Q5: TiKV 节点故障后，需要手动干预吗？ ​

A5: 对于轻度故障，如 TiKV 进程崩溃，PD 会自动进行故障恢复，不需要手动干预。对于严重故障，如节点完全不可用，可能需要手动添加新节点或移除故障节点。

Q6: 如何提高 TiKV 节点的存储可靠性？ ​

A6: 提高 TiKV 节点存储可靠性的方法包括：

  • 使用 RAID 等冗余技术
  • 配置多个磁盘，分散风险
  • 定期检查磁盘健康状态
  • 配置全面的监控和告警
  • 制定定期备份策略

Q7: TiKV 节点数据迁移需要多长时间？ ​

A7: TiKV 节点数据迁移的时间取决于数据量大小、网络带宽和集群负载等因素。一般来说，数据迁移会在后台自动进行，对业务影响较小。

Q8: 如何验证 TiKV 数据的完整性？ ​

A8: 可以使用以下方法验证 TiKV 数据的完整性：

  • 使用 tikv-ctl checksum 命令检查 Region 数据完整性
  • 执行查询语句，验证数据返回正确
  • 使用 BR 工具进行数据恢复测试
  • 定期进行全量备份和恢复演练