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

前言

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

实践过程

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

破坏环境

1
2
3
4
5
6
[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
···

查看分区情况

1
2
3
4
5
6
7
8
9
10
[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

1
2
3
4
5
6
7
8
9
[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 被使用在，还是被破坏了，这里假设上面的就是一个误操作，我们看下带来了哪些变化

1
2
[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

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

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

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

1
2
3
4
5
6
7
8
[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坏了，然后直接按照删除节点，添加节点就可以了，这个应该是最主流，最通用的处理办法，但是这个在生产环境环境当中造成的数据迁移还是非常大的，我们尝试做恢复，这就是本篇主要讲的东西
####关闭迁移

1
[root@lab8106 ceph]# ceph osd set noout

停止OSD

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

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

1
2
3
4
5
6
7
8
9
10
[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这个是要精确的值的,下面的创建会用到的

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

我们再来检查下

1
2
3
4
5
6
7
8
9
10
[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

分区表已经回来了

1
2
3
[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

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

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

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

1
2
3
4
5
6
7
[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的路径

1
2
[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

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

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

为什么有这篇

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

变更记录

Why Who When
创建 武汉-运维-磨渣 2016-09-24
修改排版 武汉-运维-磨渣 2017-03-09