前言
之前在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 |