问

oneston 2.0 PG不一致修复

8小时前提问

0关注
0收藏，44浏览

rxb

rxb 四段

粉丝：0人关注：0人

问题描述：

系统有PG不一致，在确认关闭校验后，执行修复，但系统一直未开始，请问是什么原因，要怎么处理

root@sdist1:~# ceph pg repair 1.760

instructing pg 1.760 on osd.78 to repair

root@dist1:~# ceph -s | grep repair

3 个回答

按时间按赞数

国服第181小鱼人

国服第181小鱼人四段

粉丝：2人关注：0人

你执行的 ceph pg repair 1.760 命令已经成功给主 OSD 发送了修复指令（"instructing pg 1.760 on osd.78 to repair"），但修复动作本身并未开始或未完成。这在 Ceph 中是一个常见现象，通常不是命令失败了，而是修复任务被阻塞或正在排队。

1. 为什么修复没有立即执行？

根据你的描述和搜索结果，主要有以下几个可能原因：

被其他清理任务阻塞：ceph pg repair 本质上是一种特殊的清理（scrub）操作。Ceph 对每个 OSD 上能同时运行的清理任务数量有限制（参数 osd_max_scrubs，默认值通常为 1）。如果 PG 1.760 所在的 OSD 正在执行其他的清理或深度清理，你的修复命令就会进入等待队列，直到那些任务完成才会开始。
PG 正处于恢复/回填状态：如果集群当时正在处理其他 OSD 的恢复或数据回填，PG 可能暂时无法响应修复请求。
等待深度清理完成：根据 Ceph 的代码逻辑，手动执行修复时，会先对 PG 发起一次深度清理（deep-scrub），以全面扫描并定位不一致的对象。这个深度清理过程本身就需要一定时间，尤其是当 PG 数据量较大时。你执行的 ceph pg repair 命令只是把这个任务加入了队列，并不会立即显示进度。
底层问题：虽然 fdisk -l 能看到 LUN，但可能存在 OSD 文件系统损坏、网络不稳定或磁盘有坏道等潜在问题，导致修复进程无法正常启动或反复失败。

2. 排查与处理步骤

你可以按顺序尝试以下方法，让修复工作继续进行：

第一步：检查当前阻塞修复的任务

首先，确认 PG 1.760 和其主 OSD 的当前状态。

# 1. 查看 PG 的详细状态，重点关注 "state" 字段和 "recovery_state"

ceph pg 1.760 query # 2. 检查 OSD.78 的负载，看看是否有活跃的清理或恢复任务 ceph osd perf # 或者直接查看 OSD 的日志 tail -n 100 /var/log/ceph/ceph-osd.78.log | grep -i scrub第二步：暂停其他清理任务，为修复让路

如果确认是其他清理任务阻塞，可以暂时暂停集群的所有自动清理，让修复任务能够获得资源并立即执行。

# 临时禁用自动清理

ceph osd set noscrub ceph osd set nodeep-scrub # 等待几秒钟，然后再次尝试修复 ceph pg repair 1.760 # 稍等片刻后，用以下命令观察修复是否开始 ceph pg 1.760 query | grep -A 10 "recovery_state"如果修复开始，你可能会在 recovery_state 中看到 WAITING_SCRUB、DEEP_SCRUB 等状态。修复完成后，记得重新启用自动清理：

ceph osd unset noscrub

ceph osd unset nodeep-scrub第三步：检查 OSD 日志寻找线索

如果修复仍然无法开始，直接查看 OSD 的日志能提供最直接的原因。

# 在 OSD.78 所在的主机上执行

grep "1.760" /var/log/ceph/ceph-osd.78.log | grep -E "repair|scrub|error" | tail -n 20你需要留意日志中是否有 failed to repair、blocked for 或任何与磁盘 IO 相关的错误（如 read-only file system、Input/output error）。如果有 IO 错误，问题可能出在磁盘硬件或文件系统上。

3. 如果修复最终失败或无法开始

如果尝试了上述步骤，修复依然没有动静，或者最终失败，请不要反复重试修复命令。你需要根据情况采取不同措施：

如果日志中出现：
PG.1.760 shard X: soid OBJECT digest Y != known digest Z
PG.1.760 shard X: soid OBJECT omap_digest Y != known omap_digest Z
这类“digest mismatch”（摘要不匹配）的错误不能通过 ceph pg repair 安全修复，因为它无法判断哪个副本的数据是正确的。强行修复可能导致数据损坏。在这种情况下，建议联系红帽支持或从健康的副本中手动导出/导入对象。
如果修复后 PG 状态变为 active+clean+inconsistent，但错误计数未清零：
这说明修复操作虽然执行了，但未能解决所有不一致。例如，在纠删码池中，如果有两个以上的分片数据损坏，Ceph 可能无法自动重建。
如果怀疑磁盘硬件问题：
立即检查 OSD.78 所在主机的 dmesg 和 smartctl -a /dev/sdX。如果磁盘有坏道，应该先尝试将数据迁移出该 OSD（ceph osd out osd.78），等待数据恢复完成后再处理磁盘，而不是强行修复 PG