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

前言

问题的触发是在进行一个目录的查询的时候，osd就会挂掉，开始以为是osd操作超时了，后来发现每次访问这个对象都有问题

1
2
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

1
rados -p metadata listomapvals 100006c6ddc.00000000

发现会卡住，然后关闭这个osd再次做操作，就可以了，启动后还是不行，这里可以判断是主本的对象已经有问题了，本篇将讲述多种方法来解决这个问题

处理办法

本章将会根据操作粒度的不同来讲述三种方法的恢复，根据自己的实际情况，和风险的判断来选择自己的操作

方法一：通过repair修复

首先能确定是主本损坏了，那么先把主本的对象进行一个备份，然后移除

1
2
[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

1
[root@lab71 2.0_head]# mv 100.00000000__head_C5265AB3__2 ../

注意一下在老版本的时候，对对象进行删除以后，可能元数据里面记录了对象信息，而对象又不在的时候可能会引起osd无法启动，这个在10.2.10是没有这个问题

重启osd

1
[root@lab71 2.0_head]# systemctl restart ceph-osd@0

对pg做scrub

1
2
[root@lab71 2.0_head]# ceph pg scrub 2.0
instructing pg 2.0 on osd.0 to scrub

这种方法就是需要做scrub的操作，如果对象特别多，并且是线上环境，可能不太好去做scrub的操作
检查状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[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

发起修复请求

1
2
[root@lab71 2.0_head]# ceph pg repair 2.0
instructing pg 2.0 on osd.0 to repair

修复完成后检查集群状态和对象，到这里可以恢复正常了

方法二：通过rsync拷贝数据方式恢复

跟上面一样这里首先能确定是主本损坏了，那么先把主本的对象进行一个备份，然后移除

1
2
[root@lab71 2.0_head]# systemctl stop ceph-osd@0
[root@lab71 2.0_head]# cp -ra 100.00000000__head_C5265AB3__2 ../../

移除对象

1
[root@lab71 2.0_head]# mv 100.00000000__head_C5265AB3__2 ../

在副本的机器上执行rsync命令，这里我们直接从副本拷贝对象过来，注意下不能直接使用scp会掉扩展属性

1
[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

在主本机器检查扩展属性

1
2
3
4
5
6
[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

1
[root@lab71 2.0_head]# systemctl restart ceph-osd@0

检查对象的扩展属性

1
[root@lab71 2.0_head]# rados -p metadata listomapvals 100.00000000

方法三：通过删除PG的方式恢复

这个方式是删除PG，然后重新启动的方式
这种方式操作比较危险，所以提前备份好pg的数据，最好主备pg都备份下，万一出了问题或者数据不对，可以根据需要再导入
备份PG

1
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的操作

1
2
3
4
5
6
7
[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

1
[root@lab71 current]# systemctl restart ceph-osd@0

等待回复即可

本方法里面还可以衍生一种就是，通过导出的副本的PG数据,在主本删除了相应的PG以后,进行导入的方法，这样就不会产生迁移

1
[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