好久没有更新的大剑干货，马上续上
写在前面
松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧扫码订购吧：
挺久没更新了，有读者朋友私信催更，也有问是不是公众号迁移了，哎，最近主要是比较忙，调查解决几个大坑，所以更新进度没跟上，实在抱歉，同时也对关注、支持我公众号的读者表示感谢
开始前插播一则广告，我们组目前希望可以招收一些新同事，有想往ceph方向深入的朋友可以聊聊，对ceph要求不是很高，有初步的认识，对linux、网络要求高一些，有几年工作经验更佳，如果合适的话，来到这边我会亲自做培训，有意向的朋友可以给我发发简历
好了，开场白毕，开始今天的主题，今天是一篇巡检38个集群的pg问题处理总结
PG卡在active+clean+remapped和degrade状态无法恢复clean
这种情况常见在某个故障域的osd发生故障后被删除，而迟迟未能替换新的osd进来，这就导致这个故障域的weight比其他故障域要低，这种故障域之间weight不一致的情况对crush的计算是很不友好的，很容易就会导致pg状态卡住
解决办法是，重建这个故障域的某个osd，这样使得该故障域的weight发生变化，强行触发pg重分布，进而重新进行pg的分布计算，数据均衡完后，pg就可以恢复正常了
PG卡在active+recovery_unfound+degraded+inconsistent状态
这种情况常见在pg清洗时发现了inconsistent，但是没有及时进行修复(自动修复无法成功或者没有进行手工修复)，当osd发生数据recovery和backfill时，有相关osd又发生了震荡，这种时候，pg就会找不到其中的一些对象，会卡在这种状态
解决办法是，
- 1、找到该pg的主osd，将其重启
- 2、使用
sudo ceph pg pgid mark_unfound_lost delete对卡住的部分直接删除
PG卡住在undersized+degraded
这种情况常见在osd发生down和out之后，如果集群规模比较大(osd数量在1000以上)，其中的一些磁盘默默地坏掉，其osd也默认被out掉，长时间不进行人为处理，就有可能出现这种情况
pg是active状态时，其读写都是没有问题的，只是，pg卡在undersized和degraded状态，说明它有少量数据是不完整的，为了不引发后续可能的大问题，我们需要手工做一些处理
解决办法是
- 1、如果加入了新osd，则可以直接恢复正常
- 2、如果暂时不能加入新osd，考虑重建一个osd，触发pg的重新计算
PG卡住在active+remapped+backfill_wait状态
这种情况常见于osd数据恢复途中遇到其他问题卡住，使得backfill过程卡住，解决办法很简单：
- 1、使用
sudo ceph pg PGID query查询对应pg的状态 - 2、查看上述命令的输出中的
backfill_targets字段，这个字段对应的就是卡住的osd - 3、重启该osd
PG进行scrub发现inconsistent的对象
scrub在生产环境打不打开呢？我们都是打开的，尤其是EC Pool，不打开会有一些问题，打开之后，长时间的读写，很多pg会被scrub发现有不一致的情况，即使打开了auto_repair，也不能避免一些pg无法自动修复的问题，所以我们要手工处理
解决办法是，
- 1、关闭集群的scub和deep-scrub，如果不关闭，则repair会因为获取不到资源而无法及时进行
- 2、针对有问题的pg，使用
sudo ceph pg repair PGID来修复
这里啰嗦点一下，如果集群有inconsistent的pg，而我们不及时进行修复的话，会引起其他比较大的问题，例如客户端读到这种inconsistent的obj时，会失败，导致断开
大法
嗯～～不是重启大法，最后要提的是系统时间。操作系统时间有问题，会引发很多奇奇怪怪的问题，包括一些非常诡异的pg状态，如果经过排查确定不是网络、osd、磁盘的问题的话，那最好检查一下osd节点的时间，osd节点的时间不正确或者偏差过大，是一个非常隐蔽的坑，很难发现，特此提醒
最后
集群是一个复杂的整体，pg有问题我们只能对症下药，逐个排查，以上仅作为经验总结提供参考，每个集群配置会有差异，不是说都可以百分百保证治好，不过，还是希望对大家有帮助
- 本文作者： 奋斗的松鼠
- 本文链接： http://www.strugglesquirrel.com/2020/07/24/ceph运维大宝剑之pg常见状态修复/
- 版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！