处理ceph incompelete的经验

前言

最近已经见到几个环境出现过incompelete了，这个在很久以前Jewel正在合入mark-complete工具的时候就有做过类似的处理，但是随着处理的环境越来越多，这个地方还是有些需要注意的，本篇是写一些需要注意的点

一般来说是环境有多个机器同时坏盘或者掉电，或者掉主机引起的

处理流程

拿到环境第一时间是对环境标记noout，这个操作是为了防止集群的环境反复震荡，标记noout没有osd标记为out的情况下，只是pg状态变化，实际数据并不进行迁移

把能够启动的osd都启动起来，直到没有能启动的osd了，如果有能力处理的话，尽量把osd拉起来，如果是硬盘损坏掉了，确定无法修复了，那么就当这个osd无法救回来了，这个步骤里面是要尽最大努力把osd拉起来

这里面还有一部分情况是osd启动不起来，但是数据目录是可以访问的，这个地方就把这种盘先保留好，一定不要推掉了，很多运维上去看盘坏了就重新创建osd，这种推掉osd的操作建议只在active+clean的时候才做，否则的话，pg状态不对，又把osd推掉了，数据有比较大的概率丢失

在以上操作做完以后，开始处理异常的pg，处理的时候，首先把异常的pg的info全部倒好备份一下,还把pg分布保存下

ceph pg 1.4 query > 1.4query
ceph pg dump|grep incom > pgincom.info

全部保留一份，通过这个信息能够分析出数据的完整性和数据在哪里，这个一定要保留好原始版本，这个是有可能在后面做一些操作后就变更了，造成你不知道去哪里找数据

一部分情况下，根据query的信息提示，会告诉你 lost掉某个盘，可能让它恢复，这个操作的时候也是需要检查下，这个pg的数据是不是在当前环境下面有地方有完整的数据，确定有的话再根据提示进行lost的操作，如果还不放心，或者更稳妥的话，这个时候就需要备份pg数据了，这里就有个问题了，在做系统规划的时候，系统盘要尽量大点，这个时候就可以用来保存pg导出的数据了，如果是filestore，容量不够还可以拿osd的目录做临时存储，如果是bluestore，就只能拿本地盘做临时存储了

做完上面的标记和备份的操作后，有一部分的pg可能恢复正常了，然后还有一部分恢复不了正常，这个时候就需要根据上面保存好的query的信息里面拿到pg的数据在哪个osd上面，注意这个时候当前的query是可能查不到数据在哪里的，这个时候会出现提示数据在osd.1,osd.2,osd.3实际数据在osd.8的情况，并且可能完全没地方知道是在osd.8的，这个信息是存储在最开始版本的query里面的，所以在处理前，一定备份好信息，备份好数据

这个时候就开始把pg的数据导入到主osd,导入以后就可以标记mark-complete了，然后拉起osd，然后看下处理的这个pg的状态

总结

在处理故障过程中，首先要保证能把能够拉起来的osd尽量全部拉起来，这个操作做好了可以省掉很多工作，pg是交叉映射的，有的时候正好交叉的osd全down了，所以能拉起来一个，这个pg也是可以状态恢复的

在所有操作前都是要进行数据备份的，这样即使出了问题，数据在都可以导入，导出的数据是需要检查下对象数目的，这个在导出前可以用ceph-object-tool做list操作检查pg对象的个数是否跟pg dump里面的一致的，通过大小也可以大致判断，这个在L版本的ceph做rm pg操作的时候，是有一个export-remove的命令的，这个把rm变成了mv操作，安全性比以前要好很多，防止手抖删错了，可以再导入

总之在数据处理过程中要小心，操作前备份好，操作过程每一步进行命令反馈确认，也就是你执行了命令应该是什么结果，这个要提前有分析，一旦产生偏差的时候，就要去分析了

本篇是操作上的建议，并没有具体命令，这个需要自己在实际操作过程中体会了，当然生产环境没那么多练手的机会，那么就尝试下对测试环境多进行破坏后进行恢复了，尽量不要直接推掉测试环境，每一次的问题处理都是为生产的处理做好储备工作

变更记录