前言
问题的触发是在进行一个目录的查询的时候，osd就会挂掉，开始以为是osd操作超时了，后来发现每次访问这个对象都有问题
log [WRN] ： slow request 60.793196 seconds old, received at osd_op(mds.0.188:728345234100006c6ddc.00000000 [o map-get-header 0-0,omap-get-vals 0~16,getxattr parent] snapc 0=[] ack+read+known_if_redirected+full_force e218901) currently started
heartbeat_map is_healthy ··· osd_op_tp thread ··· had timed out after 60
这个对象是元数据的一个空对象，保留数据在扩展属性当中
然后做了一个操作判断是对象损坏了:
直接列取omapkeys
rados -p metadata listomapvals 100006c6ddc.00000000
发现会卡住，然后关闭这个osd再次做操作，就可以了，启动后还是不行，这里可以判断是主本的对象已经有问题了，本篇将讲述多种方法来解决这个问题
处理办法
本章将会根据操作粒度的不同来讲述三种方法的恢复，根据自己的实际情况，和风险的判断来选择自己的操作
方法一：通过repair修复
首先能确定是主本损坏了，那么先把主本的对象进行一个备份，然后移除
[root@lab71 2.0_head]# systemctl stop ceph-osd@0
[root@lab71 2.0_head]# cp -ra 100.00000000__head_C5265AB3__2 ../../
通过ceph-object-tool进行移除的时候有bug,无法移除metadata的对象，已经提了一个bug
[root@lab71 2.0_head]# mv 100.00000000__head_C5265AB3__2 ../
注意一下在老版本的时候，对对象进行删除以后，可能元数据里面记录了对象信息，而对象又不在的时候可能会引起osd无法启动，这个在10.2.10是没有这个问题
重启osd
[root@lab71 2.0_head]# systemctl restart ceph-osd@0
对pg做scrub
[root@lab71 2.0_head]# ceph pg scrub 2.0
instructing pg 2.0 on osd.0 to scrub
这种方法就是需要做scrub的操作，如果对象特别多，并且是线上环境，可能不太好去做scrub的操作
检查状态
[root@lab71 2.0_head]# ceph -s
cluster 03580f14-9906-4257-9182-65c886e7f5a7
health HEALTH_ERR
1 pgs inconsistent
1 scrub errors
too few PGs per OSD (3 < min 30)
monmap e1: 1 mons at {lab71=20.20.20.71:6789/0}
election epoch 4, quorum 0 lab71
fsmap e30: 1/1/1 up {0=lab71=up:active}
osdmap e101: 2 osds: 2 up, 2 in
flags sortbitwise,require_jewel_osds
pgmap v377: 3 pgs, 3 pools, 100814 bytes data, 41 objects
70196 kB used, 189 GB / 189 GB avail
2 active+clean
1 active+clean+inconsistent
发起修复请求
[root@lab71 2.0_head]# ceph pg repair 2.0
instructing pg 2.0 on osd.0 to repair
修复完成后检查集群状态和对象，到这里可以恢复正常了
方法二：通过rsync拷贝数据方式恢复
跟上面一样这里首先能确定是主本损坏了，那么先把主本的对象进行一个备份，然后移除
[root@lab71 2.0_head]# systemctl stop ceph-osd@0
[root@lab71 2.0_head]# cp -ra 100.00000000__head_C5265AB3__2 ../../
移除对象
[root@lab71 2.0_head]# mv 100.00000000__head_C5265AB3__2 ../
在副本的机器上执行rsync命令，这里我们直接从副本拷贝对象过来，注意下不能直接使用scp会掉扩展属性
[root@lab72 2.0_head]# rsync -avXH /var/lib/ceph/osd/ceph-1/current/2.0_head/100.00000000__head_C5265AB3__2 20.20.20.71:/var/lib/ceph/osd/ceph-0/current/2.0_head/100.00000000__head_C5265AB3__2
在主本机器检查扩展属性
[root@lab71 2.0_head]# getfattr 100.00000000__head_C5265AB3__2
# file: 100.00000000__head_C5265AB3__2
user.ceph._
user.ceph._@1
user.ceph.snapset
user.cephos.spill_out
重启osd
[root@lab71 2.0_head]# systemctl restart ceph-osd@0
检查对象的扩展属性
[root@lab71 2.0_head]# rados -p metadata listomapvals 100.00000000
方法三：通过删除PG的方式恢复
这个方式是删除PG，然后重新启动的方式
这种方式操作比较危险，所以提前备份好pg的数据，最好主备pg都备份下，万一出了问题或者数据不对，可以根据需要再导入
备份PG
ceph-objectstore-tool --pgid 2.0 --op export --data-path /var/lib/ceph/osd/ceph-0/ --journal-path /var/lib/ceph/osd/ceph-0/journal --file /root/2.0
删除PG的操作
[root@lab71 current]# ceph-objectstore-tool --pgid 2.0 --op remove --data-path /var/lib/ceph/osd/ceph-0/ --journal-path /var/lib/ceph/osd/ceph-0/journal
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
marking collection for removal
setting \'_remove\' omap key
finish_remove_pgs 2.0_head removing 2.0
Remove successful
重启osd
[root@lab71 current]# systemctl restart ceph-osd@0
等待回复即可
本方法里面还可以衍生一种就是，通过导出的副本的PG数据,在主本删除了相应的PG以后,进行导入的方法，这样就不会产生迁移
[root@lab71 current]# ceph-objectstore-tool --pgid 2.0 --op import --data-path /var/lib/ceph/osd/ceph-0/ --journal-path /var/lib/ceph/osd/ceph-0/journal --file /root/2.0
总结
上面用三种方法来实现了副本向主本同步的操作，判断主本是否有问题的方法就是主动的把主本所在的OSD停掉，然后检查请求是否可达，在确定主本已经坏掉的情况下，就可以做将副本同步到主本的操作，可以根据PG的对象的多少来选择需要做哪种操作
变更记录
| Why | Who | When |
|---|---|---|
| 创建 | 武汉-运维-磨渣 | 2018-01-02 |