PG出现degraded或undersized本质是副本数未达标：非数据丢失，而是Ceph暂无法按配置将对象复制到足够OSD；需依次检查OSD状态、pool size/min_size配置及CRUSH映射是否匹配。
PG 出现 degraded 或 undersized，本质是副本数没达标——不是数据丢了，而是 Ceph 暂时无法按配置要求把对象复制到足够多的 OSD 上。直接查 ceph health detail 和 ceph pg dump 就能定位根因，不用猜。
先确认 OSD 是否全量 in 且 up
这两个状态是 PG 达到 active+clean 的前提。哪怕只有一台 OSD 是 out 或 down，PG 就可能卡在 undersized+degraded。
- 运行
ceph osd tree，检查所有 OSD 的状态列是否都是up和in；down表示进程挂了或网络不通，out表示被手动踢出服务范围 - 若存在
outOSD，用ceph osd in <osd.id>拉回；若为down，先查对应 OSD 日志（/var/log/ceph/ceph-osd.<id>.log），常见原因是磁盘满、权限错、或 systemd 启动失败 - 单节点实验环境必须确认
osd_crush_chooseleaf_type = 0已写入配置并生效，否则 CRUSH 规则会拒绝把多个副本放在同一 host，导致永远undersized
检查 pool 的 size / min_size 是否合理
这是最常被忽略的配置项。如果 size=3 但集群只有 2 个 OSD，PG 必然长期 undersized；如果 min_size=1，即使只有一个副本在线，PG 也会标记为 active，但数据已无冗余。
- 用
ceph osd pool get <poolname> size和min_size查当前值 - 对比
ceph osd stat输出的 OSD 总数：若size > OSD 数量，必须调小size或加 OSD，否则 PG 永远无法 clean - 修改已有 pool 需显式执行：
ceph osd pool set <poolname> size <N>（注意：不重启 OSD 即生效，但只影响后续写入） -
min_size决定写入容忍下限，设为 1 虽可绕过 degraded，但等于放弃数据保护，生产环境禁用
用 pg dump 定位具体卡在哪一步
ceph pg dump 输出里，state 列显示完整状态组合（如 active+undersized+degraded），而 up 和 acting 两列才是关键线索。
-
up列是当前 CRUSH 计算出的“应有”OSD 列表；acting是实际参与服务的 OSD 列表。两者不一致，说明部分 OSD 不可用或未完成 peering - 例如某 PG 的
up = [0,1,2]但acting = [0,1]，即第 2 个 OSD 缺失——查ceph osd status看 OSD.2 是否 down/out - 若
acting为空或含-1，说明 peering 失败，需进一步看ceph -w实时日志中是否有peering failed或unfound关键字 - 对 stuck 的 PG（如
pg4.7 is stuck undersized for 782s），优先用ceph pg repair <pgid>触发一致性检查，它比等自动恢复更可靠
别跳过 CRUSH map 和 pool 类型验证
纠删码（EC）池和复制池对 undersized 的解释完全不同：EC 池的 undersized 往往意味着 CRUSH 映射无法满足 k+m 要求，而非 OSD 数量不足。
- 运行
ceph osd pool get <poolname> type，确认是replicated还是erasure - 若是 EC 池，用
ceph osd pool get <poolname> crush_rule查规则名，再用ceph osd crush rule dump <rule_name>看其steps是否与当前 OSD 树结构冲突（比如要求跨 rack，但所有 OSD 都在 default bucket 下） - CRUSH map 错误通常表现为大量 PG 同时 stuck，而非零星几个；用
ceph osd crush dump | grep -A5 'rules'快速扫一眼规则定义是否合理 - 修改 CRUSH map 后必须执行
ceph osd setcrushmap -i <file>才生效，且需等待 PG 自动 remap，期间会短暂出现remapped状态
真正卡住的 degraded 或 undersized，90% 都落在 OSD 状态、pool size 配置、CRUSH 映射这三层。别一上来就跑 ceph pg repair，先确保 ceph osd tree 里没有灰色节点，再核对 size 和实际 OSD 数——很多“故障”只是配置和现实不匹配而已。
