• 不小心清空了Ceph的OSD的分区表如何恢复


    前言

    如果你是新手,应该出现过敲盘符的时候,敲错的情况,有些操作可能没什么问题,查询类的操作都没问题,但是写入的情况,就可能比较麻烦了,当然老手也可能有误操作,本篇将讲述在误操作把分区表给弄丢了的情况,来看看我们应该如何恢复

    实践过程

    我们现在有一个正常的集群,我们假设这些分区都是一致的,用的是默认的分区的方式,我们先来看看默认的分区方式是怎样的

    破坏环境

    [root@lab8106 ceph]# ceph-disk  list
    ···
    /dev/sdb :
     /dev/sdb1 ceph data, active, cluster ceph, osd.0, journal /dev/sdb2
     /dev/sdb2 ceph journal, for /dev/sdb1
    ···
    

    查看分区情况

    [root@lab8106 ceph]# parted -s /dev/sdb print
    Model: SEAGATE ST3300657SS (scsi)
    Disk /dev/sdb: 300GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Disk Flags: 
    
    Number  Start   End     Size    File system  Name          Flags
     2      1049kB  1074MB  1073MB               ceph journal
     1      1075MB  300GB   299GB   xfs          ceph data
    

    来一个破坏,这里是破坏 osd.0,对应盘符 /dev/sdb

    [root@lab8106 ceph]# ceph-deploy disk zap lab8106:/dev/sdb
    [ceph_deploy.conf][DEBUG ] found configuration file at: /root/.cephdeploy.conf
    [ceph_deploy.cli][INFO  ] Invoked (1.5.34): /usr/bin/ceph-deploy disk zap lab8106:/dev/sdb
    ···
    [lab8106][DEBUG ] Warning: The kernel is still using the old partition table.
    [lab8106][DEBUG ] The new table will be used at the next reboot.
    [lab8106][DEBUG ] GPT data structures destroyed! You may now partition the disk using fdisk or
    [lab8106][DEBUG ] other utilities.
    ···
    

    即使这个 osd 被使用在,还是被破坏了,这里假设上面的就是一个误操作,我们看下带来了哪些变化

    [root@lab8106 ceph]# ll /var/lib/ceph/osd/ceph-0/journal
    lrwxrwxrwx 1 root root 58 Sep 24 00:02 /var/lib/ceph/osd/ceph-0/journal -> /dev/disk/by-partuuid/bd81471d-13ff-44ce-8a33-92a8df9e8eee
    

    如果你用命令行看,就可以看到上面的链接已经变红了,分区没有了

    [root@lab8106 ceph]# ceph-disk  list 
    /dev/sdb :
     /dev/sdb1 other, xfs, mounted on /var/lib/ceph/osd/ceph-0
     /dev/sdb2 other
    

    已经跟上面有变化了,没有ceph的相关信息了

    [root@lab8106 ceph]# parted -s /dev/sdb print
    Model: SEAGATE ST3300657SS (scsi)
    Disk /dev/sdb: 300GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Disk Flags: 
    
    Number  Start  End  Size  File system  Name  Flags
    

    分区表完全没有信息了,到这我们可以确定分区表完全没了,如果现在重启将会发生什么?重启以后这个磁盘就是一个裸盘,没有分区的裸盘

    处理办法

    首先一个办法就是当这个OSD坏了,然后直接按照删除节点,添加节点就可以了,这个应该是最主流,最通用的处理办法,但是这个在生产环境环境当中造成的数据迁移还是非常大的,我们尝试做恢复,这就是本篇主要讲的东西

    关闭迁移

    [root@lab8106 ceph]# ceph osd set noout
    

    停止OSD

    [root@lab8106 ceph]# systemctl stop ceph-osd@0
    

    现在的OSD还是有进程的,所以需要停止掉再做处理
    通过其他节点查看分区的信息

    [root@lab8106 ceph]# parted -s /dev/sdc  unit s print
    Model: SEAGATE ST3300657SS (scsi)
    Disk /dev/sdc: 585937500s
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Disk Flags: 
    
    Number  Start     End         Size        File system  Name          Flags
     2      2048s     2097152s    2095105s                 ceph journal
     1      2099200s  585937466s  583838267s  xfs          ceph data
    

    我们现在进行分区表的恢复,记住上面的数值,我print的时候是加了unit s这个是要精确的值的,下面的创建会用到的

    [root@lab8106 ceph]# parted -s /dev/sdb  mkpart  primary  2099200s 585937466s
    [root@lab8106 ceph]# parted -s /dev/sdb  mkpart  primary  2048s 2097152s
    

    我们再来检查下

    [root@lab8106 ceph]# parted -s /dev/sdb  print
    Model: SEAGATE ST3300657SS (scsi)
    Disk /dev/sdb: 300GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Disk Flags: 
    
    Number  Start   End     Size    File system  Name     Flags
     2      1049kB  1074MB  1073MB               primary
     1      1075MB  300GB   299GB   xfs          primary
    

    分区表已经回来了

    [root@lab8106 ceph]# umount /var/lib/ceph/osd/ceph-0
    [root@lab8106 ceph]# partprobe
    [root@lab8106 ceph]# mount /dev/sdb1 /var/lib/ceph/osd/ceph-0
    

    我们重新挂载看看,没有问题,还要做下其他的处理

    [root@lab8106 ceph]# rm -rf /var/lib/ceph/osd/ceph-0/journal
    

    我们先删除掉journal的链接文件

    [root@lab8106 ceph]# ceph-osd -i 0 --osd-journal=/dev/sdb2 --mkjournal
    SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 01 cf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    2016-09-24 00:36:06.595992 7f9d0afbc880 -1 created new journal /dev/sdb2 for object store /var/lib/ceph/osd/ceph-0
    [root@lab8106 ceph-0]# ln -s /dev/sdb2 /var/lib/ceph/osd/ceph-0/journal
    [root@lab8106 ceph-0]# chown ceph:ceph /var/lib/ceph/osd/ceph-0/journal
    [root@lab8106 ceph-0]# ll /var/lib/ceph/osd/ceph-0/journal
    lrwxrwxrwx 1 ceph ceph 9 Sep 24 00:37 journal -> /dev/sdb2
    

    上面操作就是创建journal相关的,注意下我上面的操作--osd-journal=/dev/sdb2这个地方,我是便于识别,这个地方要写上dev/sdb2的uuid的路径

    [root@lab8106 ceph-0]# ll /dev/disk/by-partuuid/03fc6039-ad80-4b8d-86ec-aeee14fb3bb6 
    lrwxrwxrwx 1 root root 10 Sep 24 00:33 /dev/disk/by-partuuid/03fc6039-ad80-4b8d-86ec-aeee14fb3bb6 -> ../../sdb2
    

    也就是这个链接的这一串,这个防止盘符串了情况下journal无法找到的问题

    启动osd

    [root@lab8106 ceph-0]# systemctl start ceph-osd@0
    

    检查下,到这osd就正常的恢复了

    为什么有这篇

    一直都知道分区表是可以恢复的,也一直知道会有误操作,但是一直没有去把ceph中完整流程走下来,前两天一个哥们环境副本一,然后自己给搞错了,出现不得不恢复的情况,正好自己一直想把这个问题的处理办法给记录下来,所以就有了这篇,万一哪天有人碰到了,就把这篇发给他

    变更记录

    Why Who When
    创建 武汉-运维-磨渣 2016-09-24
    修改排版 武汉-运维-磨渣 2017-03-09
  • 相关阅读:
    BZOJ 1021 循环的债务
    BZOJ 1019 汉诺塔
    BZOJ 1018 堵塞的交通
    BZOJ 1017 魔兽地图
    BZOJ 1016 最小生成树计数
    Luogu 3008 [USACO11JAN]道路和飞机Roads and Planes
    Luogu 3625 [APIO2009]采油区域
    Luogu 4139 上帝与集合的正确用法
    Luogu 3629 [APIO2010]巡逻
    Luogu 3626 [APIO2009]会议中心
  • 原文地址:https://www.cnblogs.com/zphj1987/p/13575371.html
Copyright © 2020-2023  润新知