zoukankan      html  css  js  c++  java
  • bluestore对象挂载到系统进行提取

    前言

    之前在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
  • 相关阅读:
    learning scala view collection
    scala
    learning scala dependency injection
    learning scala implicit class
    learning scala type alise
    learning scala PartialFunction
    learning scala Function Recursive Tail Call
    learning scala Function Composition andThen
    System.Threading.Interlocked.CompareChange使用
    System.Threading.Monitor的使用
  • 原文地址:https://www.cnblogs.com/zphj1987/p/13575461.html
Copyright © 2011-2022 走看看