Ceph PG不一致修复实战：从scrub errors到HEALTH_OK的完整排查手册

Ceph PG不一致修复实战：从scrub errors到HEALTH_OK的完整排查手册

在分布式存储系统的日常运维中，没有什么比看到集群健康状态从HEALTH_OK变成HEALTH_ERR更让人心跳加速的了。特别是当错误信息里出现"scrub errors"和"pg inconsistent"这些字眼时，经验丰富的运维工程师都知道，这不仅仅是简单的警告，而是数据一致性可能受到威胁的明确信号。Ceph集群的PG不一致问题，就像存储系统里的"慢性病"，初期可能只是偶尔的scrub错误，但如果处理不当，可能会演变成数据损坏甚至服务中断的"急性发作"。

今天我们要深入探讨的，正是这个让无数Ceph运维工程师头疼的问题。不同于官方文档的标准流程，我将分享一套经过实战检验的排查和修复方法论，特别是当常规的ceph pg repair命令失效时，如何通过更底层的操作让集群恢复健康。无论你是刚刚接触Ceph的新手，还是已经管理过PB级集群的老兵，这篇文章都将为你提供从理论到实践的完整指导。

1. 理解PG不一致：从表象到本质

在深入修复之前，我们首先要明白PG不一致到底意味着什么。Ceph的Placement Group（PG）是数据分布和复制的基本单位，每个PG在多个OSD上维护副本。当Ceph执行scrub操作时，它会比较同一PG在不同OSD上副本的校验和，如果发现不匹配，就会标记该PG为inconsistent状态。

1.1 不一致的常见触发场景

从我处理过的数十个案例来看，PG不一致通常源于以下几种情况：

• 硬件故障：这是最常见的原因。磁盘坏道、内存错误、网络闪断都可能导致数据写入或读取时出现差异
• 软件bug：Ceph版本升级过程中的兼容性问题，或者特定版本中的已知bug
• 并发操作冲突：在高并发写入场景下，不同副本间的同步延迟可能导致短暂的不一致
• 运维操作失误：比如在数据恢复过程中强制重启OSD，或者不恰当的配置变更

1.2 诊断不一致的严重程度

不是所有的inconsistent状态都同样危险。我们需要根据具体信息判断问题的严重性：

# 查看详细的健康状态
ceph health detail

# 查看特定PG的详细信息
ceph pg <pg_id> query

关键是要关注错误信息中的细节。比如，如果日志中出现的是"digest mismatch"（校验和不匹配），这通常意味着数据本身可能已经损坏。而如果是"missing attr"（属性缺失），问题可能相对容易解决。

注意：根据红帽官方文档的警告，如果日志中出现特定类型的校验和错误，不要尝试自行修复，应该立即联系技术支持。这些错误包括： <pg.id> shard <osd>: soid <object> digest <digest> != known digest <digest> <pg.id> shard <osd>: soid <object> omap_digest <digest> != known omap_digest <digest>

1.3 不一致状态的类型分析

Ceph中的不一致状态有多种表现形式，理解这些状态有助于我们制定正确的修复策略：

在实际生产环境中，我遇到过这样一个案例：一个三副本的PG，其中一个副本因为磁盘坏道导致部分对象无法读取，而另外两个副本的数据是一致的。这种情况下，Ceph会尝试从健康的副本恢复数据，但如果坏道影响了关键元数据，恢复过程可能会失败。

2. 标准修复流程：从简单到复杂

当发现PG不一致时，我们应该遵循从简单到复杂的修复原则。很多情况下，问题可以通过标准流程解决，无需进行复杂的底层操作。

2.1 第一步：基础信息收集

在开始任何修复操作之前，充分的信息收集是成功的关键。我们需要了解：

1. 受影响PG的完整信息：

   # 查找所有不一致的PG
   ceph pg dump | grep inconsistent
   
   # 或者使用更详细的JSON格式
   ceph pg dump --format=json-pretty | jq '.pg_stats[] | select(.state | contains("inconsistent"))'
   

2. PG的分布情况：

   # 查看PG的acting set（当前负责的OSD列表）
   ceph pg <pg_id> query | grep -A5 "acting"
   
   # 示例输出
   # "acting": [5, 7, 4],
   # "up": [5, 7, 4],
   # "acting_primary": 5
   

3. 相关OSD的状态：

   # 检查OSD是否在线
   ceph osd tree | grep -E "(osd\.5|osd\.7|osd\.4)"
   
   # 查看OSD的详细状态
   ceph osd dump | grep -A10 "osd.5"
   

2.2 第二步：尝试标准修复命令

对于大多数轻微的不一致问题，Ceph自带的修复命令就能解决问题：

# 标准修复命令
ceph pg repair <pg_id>

# 示例
ceph pg repair 6.d

这个命令的工作原理是：Ceph会选择一个"权威"副本（通常是primary OSD上的副本），然后用它来覆盖其他不一致的副本。修复过程大致分为几个阶段：

1. 识别阶段：PG的primary OSD会与其他副本通信，收集所有对象的元数据和校验和
2. 比较阶段：对比不同副本间的差异，确定哪些对象需要修复
3. 修复阶段：用权威副本的数据覆盖不一致的副本
4. 验证阶段：再次检查修复后的数据一致性

提示：在执行修复命令后，可以通过ceph -w实时观察集群状态变化。修复过程可能会持续几分钟到几小时，具体取决于PG的大小和集群负载。

2.3 第三步：深度清理与验证

如果标准修复命令没有解决问题，可以尝试更彻底的清理操作：

# 执行深度scrub
ceph pg deep-scrub <pg_id>

# 等待深度scrub完成后，再次尝试修复
ceph pg repair <pg_id>

深度scrub与普通scrub的主要区别在于：

• 普通scrub：只检查对象的元数据和部分数据的校验和，速度快但对系统影响小
• 深度scrub：读取对象的全部数据并计算完整校验和，更彻底但消耗更多I/O资源

在我的经验中，大约有60%的PG不一致问题可以通过ceph pg repair解决，30%需要结合深度scrub，剩下的10%则需要更复杂的处理。

3. 当标准修复失效：五种进阶解决方案

如果ceph pg repair命令执行后问题依旧，或者修复过程中出现新的错误，我们就需要进入"专家模式"。以下是五种经过实战检验的进阶解决方案。

3.1 方案一：OSD重启与日志刷盘

这是最常用且相对安全的进阶操作。当PG的某个副本所在OSD出现短暂故障或内存状态不一致时，这种方法往往有效。

操作步骤：

1. 定位问题OSD：

   # 找到PG所在的主OSD
   ceph pg <pg_id> query | grep "acting_primary"
   
   # 找到所有相关的OSD
   ceph pg <pg_id> query | grep -A2 "acting"
   

2. 按顺序重启OSD（建议从非primary OSD开始）：

   # 停止OSD服务
   systemctl stop ceph-osd@<osd_id>.service
   
   # 刷入日志（确保所有待写入数据落盘）
   ceph-osd -i <osd_id> --flush-journal
   
   # 重新启动OSD
   systemctl start ceph-osd@<