1 osd increase the log level
Red box plus the line on it
osd log path: /var/log/ceph/ceph-osd.3.log
Note: After adding this line logs will brush a lot, so pay special attention to changes in the log capacity, to prevent the var directory filled
2 missing osdmap or wrong osdmap
From osd find both the error log belong osdmap not normal, from other normal osd copy on osdmap start error to the corresponding osd the assumed abnormal osdmap number is 816 , the figure is 27 601 and 671 651
As the following chart:
In a normal osd on as osd.4 with the find Find command 816 of osdmap
Followed by scp command files are copied to the corresponding error corresponding starting osd the corresponding directory
3 file repair leveldb
This error is a lack omap of sst file, you can try leveldb built-in repair tool to repair
Installation leveldb modules:
yum install epel-release -y
yum install python-pip python-devel gcc gcc-c++ -y
pip install --upgrade pip
pip install leveldb
Note: The pip such a time-out error may occur when the command is executed again if there pip command to
Repair command (assumed to be repaired osd.0 ):
Press the red box shown in FIG performed:
After repair under repair out whether how can view the catalog ldb file with the extension, if through mv renamed the suffix to sst
mv /var/lib/ceph/osd/ceph-0/current/omap/000009.ldb /var/lib/ceph/osd/ceph-0/current/omap/000009.sst
Change the file name and then restart the osd.0 look.
If such an error will be reported below, it is like the first 2 Dian copies of the same steps corresponding osdmap over and then restart
4 yuan data parity error
该错误是由于遍历加载pg的omap时出错导致osd起不来，如上图的报错是1.13这个pg报错导致的，如果只是单个pg有问题，在其它osd上有存储，那大可去除该pg，但我们遇到的在客户那里的情况是每个pg都有问题，那就感觉不是某个pg的问题了，是一个osd的共性问题，很有可能是leveldb的问题，但用leveldb修复却不能修复好，还未有解决方法
5 Inconsistent的pg
有这种pg出现在ceph -s命令的输出中应该可以看到有类似1 pgs inconsistent这样的描述，使用命令：
ceph health detail | grep inconsistent
找出inconsistent的pg，比如是pg 1.1
一般情况下使用以下命令即可修复不一致的pg：
ceph pg repair 1.1
执行完后等待一段时间可能会自动修复好
如果一段时间后也没修复好，则可以尝试再执行一遍，如果还没修复好则需要找出不一致的object来处理了
首先从osd的日志里找到inconsistent的obj
列出该object：
如果是3副本，则可以通过md5计算下哪个是不一致的，从而删除掉该object让其同步另外两个的即可，但这里的错误其实并不是object文件内容上的不一致，而是缺少object文件的一些文件属性，查看正常的：
异常的则没有红框里的属性且用object-ceph-tool查看时会报这样的错：
可以将正常的object拷贝覆盖异常的object：
注意：这里要用rsync来拷贝，这样文件属性也才能拷贝过去
6 pg down的处理
可先通过ceph pg query x.x来看某pg的情况，翻到最后面的recover项会有说明该pg为什么down且建议你如何恢复的说明
pg down的意思是含有最新数据pg的对应的osd没起来，最简单的做法就是将该osd拉起来，但如果该osd实在拉不起来且已经把它移出集群了，则可以告诉集群那个主pg的osd已经丢失了，让其它副本的pg作为主osd，比如osd.5已经起不来了则：
ceph osd lost 5 --yes-i-really-mean-it
当然这样也意味着主pg上有一些数据副pg是没有的，可能会有一些数据丢失，如果想要保险，则可以通过object-ceph-tool工具将pg从挂掉的那个osd上先导出来，然后再通过该工具导入到正常的有该副本的osd上即可
注意：如果确实想把某osd标记为lost，则应该那个osd从osd crush中remove出去才有效
7 终极恢复方法
该方法的原理是通过将一个rbd的所有object收集起来重新拼接成一个raw格式的文件，然后可将该文件导入到虚拟存储中重新成为一个rbd
脚本文件下载地址：https://github.com/luohaixiannz/ceph-recovery-master
情景假设：
假设虚拟存储中一共有3个osd，osd.0、osd.1和osd.2
使用方法：
（1）找一个空间大一点的目录，需要比ceph df中显示的容量要大
比如这里显示的是103M，则我们选的目录的存放的空间应该大于这个容量的2倍以上，因为我们拼接后输出的文件也存放到该目录下
解压脚本文件到该目录
（2） 创建目录
cd ceph-recovery-master
mkdir outputs
mkdir osds
cd osds
mkdir osd0 osd1 osd2
cd ..
通过scp的方式将3个osd的current目录拷贝到对应的刚刚创建的osd目录下，比如osd0的（其它节点上的则用scp）：
cp -r /var/lib/ceph/osd/ceph-0/current ceph-recovery-master/osds/osd0/
（3） 运行脚本
a. 收集osd里的object数据
执行命令：
./collect_files.sh osds
b. 查找要恢复的rbd
找虚拟机的系统盘可按如下图的命令找对应关系：
如果是找数据盘的则按如下图的命令找对应关系：
如果是镜像的则：
上面列举了我们知道名字如何找到对应的uuid，这个uuid是用来下一步恢复rbd时使用
c. 恢复rbd为一个raw的文件
比如我们想恢复testooo这个虚拟机的系统盘，则按上图那些操作我们可以得知它对应的uuid是a4f0234a-e900-4d3c-a684-4d9fe4d1abc3
则执行如下命令：
获取到这个虚拟机系统盘对应的rbd的uuid
执行命令恢复这个rbd为一个raw格式的文件：
这里解释下该命令传递的参数含义：
（1）那个disk.id那一串就是我们上面找的rbd对应的uuid
（2）参数2表示2M，以M为单位，代表的含义是这个rbd的object是定义为2M的，这个可以通过rbd info pool_name/rbdname里可以看到
（3）参数5表示该磁盘的大小，以G为单位
命令执行完成后，脚本会将拼接后的raw文件放在outputs目录下：
d. 验证rbd是否正常
如果你当前的ceph环境是异常的，则很明显你不能用当前ceph环境来验证，可以通过其它ceph环境来验证该raw文件是否是正常的。
ceph环境下的验证方法，先导入该raw文件为一个rbd
查看是否导入进去了：
然后新创建一个虚拟机，然后找到它的rbd名字，然后通过rbd rename的方式交换两个rbd，然后开启这个虚拟机看是否正常即可
数据盘的方式也是用替换rbd的方式来验证的
上面说的是用ceph环境来验证到处的rbd是否是正常的，如果当前ceph不可用则可用本地存储来验证，本地存储使用的磁盘格式是qcow2的，所以我们先要将raw格式的磁盘转换为qcow2格式的：
然后新建一个本地虚拟机，用转换出来的qcow2文件替换掉它的qcow2文件，然后开启虚拟机检查下磁盘是否是正常的