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

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

我们选择一个pg 1.7

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

检查挂载点

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

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

我们把osd的数据挂载起来

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

开另外一个终端

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

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

我们随便选取一个对象

[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

我们把数据弄到本地

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

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

[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

现在就有下面两个对象了

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

[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