Ceph对象主本损坏的修复方法


dog

前言

问题的触发是在进行一个目录的查询的时候,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