bluestore对象挂载到系统进行提取

前言

之前在filestore里面,pg是直接暴露到文件系统的,也就是可以直接进去查看或者拷贝,在极端情况下,多个osd无法启动,pg无法导出的时候,那么对pg内部对象的操作处理,是可以作为最后恢复数据的一种方式的

这个在bluestore里面就没那么直接了,之前也碰到过一次,osd无法启动,内部死循环,pg无法export,osd就僵死在那里了,实际上,bluestore也提供了接口把对象能够直接显示出来

具体操作实践

我们选择一个pg 1.7

1
2
3
[root@lab101 ceph]# ceph pg dump|grep 1.7
dumped all
1.7 128 0 0 0 0 524353536 1583 1583 active+clean 2019-07-26 10:05:17.715749 14'3583 14:3670 [1] 1 [1] 1 0'0 2019-07-26 10:01:20.337218 0'0 2019-07-26 10:01:20.337218

可以看到pg 1.7是有128个对象存储在osd.1上

检查挂载点

1
2
[root@lab101 ceph]# df -h|grep ceph-1
tmpfs 16G 48K 16G 1% /var/lib/ceph/osd/ceph-1

可以看到是挂载到tmpfs的,我们先停止掉osd.1

我们把osd的数据挂载起来

1
2
[root@lab101 ceph]# ceph-objectstore-tool --op fuse --data-path /var/lib/ceph/osd/ceph-1 --mountpoint /osdmount/
mounting fuse at /osdmount/ ...

开另外一个终端

1
2
[root@lab101 ~]# df -h|grep osdmount
foo 3.7T 3.7T 3.7T 51% /osdmount

可以看到有了新的挂载点,我们看下里面的数据结构

我们随便选取一个对象

1
2
3
4
[root@lab101 ~]# ll /osdmount/1.7_head/all/#1\:fc00bae4\:\:\:rbd_data.10166b8b4567.00000000000001fc\:head#/data
-rwx------ 1 root root 4194304 Jan 1 1970 /osdmount/1.7_head/all/#1:fc00bae4:::rbd_data.10166b8b4567.00000000000001fc:head#/data
[root@lab101 ~]# md5sum /osdmount/1.7_head/all/#1\:fc00bae4\:\:\:rbd_data.10166b8b4567.00000000000001fc\:head#/data
7def453c4a818e6cd542bfba4dea9943 /osdmount/1.7_head/all/#1:fc00bae4:::rbd_data.10166b8b4567.00000000000001fc:head#/data

这个对象的名称为:rbd_data.10166b8b4567.00000000000001fc

我们把数据弄到本地

1
[root@lab101 ~]# cp /osdmount/1.7_head/all/#1\:fc00bae4\:\:\:rbd_data.10166b8b4567.00000000000001fc\:head#/data /tmp/rbd_data.10166b8b4567.00000000000001fc-inbluestore

我们通过rados的接口查询获取这个对象

1
2
3
[root@lab101 ceph]# rados -p rbd ls|grep 00000000000001fc
rbd_data.10166b8b4567.00000000000001fc
[root@lab101 ceph]# rados -p rbd get rbd_data.10166b8b4567.00000000000001fc /tmp/rbd_data.10166b8b4567.00000000000001fc-radosget

现在就有下面两个对象了

1
2
3
[root@lab101 ceph]# ls /tmp/rbd_data.10166b8b4567.00000000000001fc-* -hl
-rwx------ 1 root root 4.0M Jul 26 10:17 /tmp/rbd_data.10166b8b4567.00000000000001fc-inbluestore
-rw-r--r-- 1 root root 4.0M Jul 26 10:19 /tmp/rbd_data.10166b8b4567.00000000000001fc-radosget

这两个对象分别从rados获取的,也就是前端获取的,一个从底层磁盘提取的,也就是模拟的故障提取

我们来比较一下两个文件的md5值

1
2
3
[root@lab101 ceph]# md5sum /tmp/rbd_data.10166b8b4567.00000000000001fc-* 
7def453c4a818e6cd542bfba4dea9943 /tmp/rbd_data.10166b8b4567.00000000000001fc-inbluestore
7def453c4a818e6cd542bfba4dea9943 /tmp/rbd_data.10166b8b4567.00000000000001fc-radosget

可以看到文件的内容一样的了

因此通过这个方法在底层获取对象是可以获取到正确的对象的

总结

之前对bluestore的感觉一直不太好,是因为一旦出现故障,数据的提取相当困难,之前还有过bluestore内部数据库损坏无法启动osd的,如果用过filestore,应该都做过很多故障的修复,leveldb的数据库的损坏,从其他机器弄回来,bluestore这个在封装以后,一些操作变的困难,虽然也有提供一些repair的工具,但是有时还是无法生效,并不是每个人都能够去做代码级的修复

随着文件系统对外接口提供的越来越多的时候,修复的方式方法也会增多,相信这个也会越来越稳定的,我们需要做的就是,在任何故障下,做最大的可能去修复,才能更好的面对未来的故障

变更记录

Why Who When
创建 武汉-运维-磨渣 2019-07-26