!! 大家好，我是wanger，一个爱折腾的运维工程，一个睡觉都被自己丑醒的云原生爱好者。
作者：wanger
公众号：运维开发故事
博客：https://www.devopstory.cn/
一、事故背景
在一次异常重启后，Ceph 集群出现了 PG 状态异常、部分 RBD 镜像无法正常启动等问题。本文记录了从 PG 状态检查、unfound object 定位、RBD 镜像关联分析，到后续 OSD 异常处理和业务数据恢复的完整排查过程。
二、初步排查
-
查看当前ceph health detail, 显示pg2.0和pg2.1f各有一个对象丢失
ceph health detail
-
执行pg查询命令,发现主副本侧少了一个对象
|
|
|---|
这里也能看到有一个对象没有分配在任何一个副本上
-
查看这两个pg丢失的对象属于哪个镜像，这两个pg丢失的对象分别是rbd_data.3d9eda62e65b28.000000000011880
rbd_data.4aa6c99c7c8b2.0000000000012e6，
中间的3d9eda62e65b28和4aa6c99c7c8b2就是镜像id，后面的是具体的对象名，可以根据这个镜像id查是哪个虚拟机丢失的对象
plain ceph pg 2.0 list_unfound ceph pg 2.1f list_unfound |
|---|
-
使用rbd info命令查找哪个虚拟机镜像是这个id，发现分别属于两个虚拟机
-
对这两个虚拟机做快照备份，并关闭虚拟机
现在这两个对象已经无法找回了，需要对其标记为丢失
plain ceph pg 2.0 mark_unfound_lost revert ceph pg 2.1f mark_unfound_lost revert |
|---|
-
执行后报错已经没了，还剩pg副本不一致的错误
直接对pg进行ceph pg repair 2.0 修复，如果还提示报错则执行ceph pg 2.0 deep-scrub
-
执行此命令可以将pg不一致的对象列出来，这里发现其实已经没有不一致的对象了
plain rados list-inconsistent-obj 2.0 rados list-inconsistent-obj 2.1f |
|---|
虚拟机开机后显示如下状态
pg 2.0 里有一个 RBD 对象在多个 OSD 上读失败，也就是断电还是导致了底层数据损坏
三、 第二阶段：OSD 崩溃
-
在将pg2.0对应的osd手动重启后，发现pg出现inactive，导致整个集群无法读写
手动启动那两个osd后，发现osd在 recover_backfill 的时候触发断言无法启动，关掉 recover和backfill后就正常了
根据现象发现是和 tracker上记录的 #57940（已标成 #56772 的重复问题）一致，是个已知的bug。
根据上面https://tracker.ceph.com/issues/56772说的移除其他两个pg副本，强制同步剩下的pg副本的方法也并不管用。
-
查了下2.1f的peering 被历史上参与过这个 PG 的 down OSD 卡住了，当前 PG 2.1f 要完成 peering，还想去问 osd.3 和 osd.8，但这两个 OSD 现在是 down。
-
数据同步给其他osd之后做了ceph osd lost 8 和ceph osd lost 3 操作，发现还是有inactive的状态，现在又变成了pg2.6一直在peering中
四、升级ceph版本
因为当前环境是17.2.6的版本，17版本还在支持的是17.2.9，因此决定从17.2.6升级到17.2.9看看是否还存在这个问题。新版本会把断言改成安全判断，不再崩溃。
升级版本后发现是pg没有卡在那个有故障的osd上了
不过当我把min_size从3改为2后，没多久又出现了同样的断言问题，看样子即使升级到17.2.9版本也没有解决这个问题
五、后续尝试
-
对pg的所有snap进行处理
具体的处理步骤我这边丢失了，这里把参考的ceph大佬的步骤贴一下
1、首先获取pg包含的所有object列表
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-10/ --type bluestore --pgid 10.276 --op list
2、删除pg中object的snap信息
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-10/ --type bluestore --pgid 10.276 rbd_data.23d1114e645816.0000000000014804 remove-clone-metadata 4
不过即使删除了所在pg的snap数据后osd也一样会触发断言。
-
删除触发断言的镜像文件，删除后并把对应的osd标记为ceph osd lost 4 --yes-i-really-mean-it，结果inactive状态仍然存在。
看了下虚拟机状态，发现系统都读不到引导分区了，后面通过挂载ISO的方式修复了引导分区和文件系统，并把虚拟机的数据做了备份，这里不表。
后面就重置了整个存储池，重新在上面部署了业务。
如果我的文章对你有所帮助，还请帮忙点赞、在看、转发一下，你的支持会激励我输出更高质量的文章，非常感谢！
你还可以把我的公众号设为「星标」，这样当公众号文章更新时，你会在第一时间收到推送消息，避免错过我的文章更新。
我是 wanger，《运维开发故事》公众号团队中的一员，一线运维农民工，云原生实践者，这里不仅有硬核的技术干货，还有我们对技术的思考和感悟，欢迎关注我们的公众号，期待和你一起成长！
