前言 如果你是新手,应该出现过敲盘符的时候,敲错的情况,有些操作可能没什么问题,查询类的操作都没问题,但是写入的情况,就可能比较麻烦了,当然老手也可能有误操作,本篇将讲述在误操作把分区表给弄丢了的情况,来看看我们应该如何恢复
实践过程 我们现在有一个正常的集群,我们假设这些分区都是一致的,用的是默认的分区的方式,我们先来看看默认的分区方式是怎样的
破坏环境 1 2 3 4 5 6 [root@lab8106 ceph] ··· /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] 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.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] 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] /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] 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坏了,然后直接按照删除节点,添加节点就可以了,这个应该是最主流,最通用的处理办法,但是这个在生产环境环境当中造成的数据迁移还是非常大的,我们尝试做恢复,这就是本篇主要讲的东西 ####关闭迁移
停止OSD
现在的OSD还是有进程的,所以需要停止掉再做处理 通过其他节点查看分区的信息
1 2 3 4 5 6 7 8 9 10 [root@lab8106 ceph] 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] [root@lab8106 ceph]
我们再来检查下
1 2 3 4 5 6 7 8 9 10 [root@lab8106 ceph] 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] [root@lab8106 ceph] [root@lab8106 ceph]
我们重新挂载看看,没有问题,还要做下其他的处理
我们先删除掉journal的链接文件
1 2 3 4 5 6 7 [root@lab8106 ceph] 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] [root@lab8106 ceph-0] [root@lab8106 ceph-0] 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] lrwxrwxrwx 1 root root 10 Sep 24 00:33 /dev/disk/by-partuuid/03fc6039-ad80-4b8d-86ec-aeee14fb3bb6 -> ../../sdb2
也就是这个链接的这一串,这个防止盘符串了情况下journal无法找到的问题
启动osd
检查下,到这osd就正常的恢复了
为什么有这篇 一直都知道分区表是可以恢复的,也一直知道会有误操作,但是一直没有去把ceph中完整流程走下来,前两天一个哥们环境副本一,然后自己给搞错了,出现不得不恢复的情况,正好自己一直想把这个问题的处理办法给记录下来,所以就有了这篇,万一哪天有人碰到了,就把这篇发给他
变更记录
Why
Who
When
创建
武汉-运维-磨渣
2016-09-24
修改排版
武汉-运维-磨渣
2017-03-09