一次有点脑洞的问题处理
开始
关于osd的问题总是各种各样,奇奇怪怪,有bug相关的,也有环境相关的,或者是配置相关的,对于osd各种问题的处理,重点在思路,思路对了,问题就好解决了。
本篇是一个集群有ssd的osd发生down,这本不是什么值得关注的事,osd的down太常见了,多为坏盘引发,但奇怪的是它down并不是配置、环境、硬件引发,十分奇怪。
因此松鼠哥在本篇尽可能从思路角度分析,希望对大家有帮助。
排查
首先osd的down应该是看它的日志,报错比较明显:
1 | -465> 2024-09-19 22:33:50.439 7f4877aee700 2 rocksdb: [/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/gigantic/release/13.2.10/rpm/el7/BUILD/ceph-13.2.10/src/rocksdb/db/db_impl_compaction_flush.cc:1517] Waiting after background compaction error: Corruption: block checksum mismatch: expected 3752980306, got 1569966253 in db/175779.sst offset 2206199009 size 4080, Accumulated background error counts: 1 |
是rocksdb的sst文件它的checksum有问题,通常,这种checksum问题大概率就是对应的地方有坏道、逻辑错误等,由于osd使用了blustore,我们能够对rocksdb进行的操作十分有限,而且sst文件损坏并不容易修复,因此最好采取的办法就是重建该osd,简单粗暴但有效。
于是,松鼠哥先对该osd进行了删除,然后进行重建,重建完成后,osd拉起来,数据均衡一会后,发现仍然报checksum的错误:
1 | -10001> 2024-09-20 00:53:41.753 7fd7d43bf700 -1 rocksdb: submit_common error: Corruption: block checksum mismatch: expected 2253949442, got 530591794 in db/000178.sst offset 2147479191 size 40720033-pop^N\+UV code = 2 Rocksdb transaction: |
报错信息与此前相比有所不同,但都是checksum的问题,关键是,多次重建发现,osd居然都报同样的错误,更奇怪的是,多次重建发现它报错的文件名字是一样的,重建了个寂寞??
按道理讲,重建osd后,osd上是完全没有数据的,这些数据都需要从别的osd通过backfill得到,那么就不太可能产生问题才对,有没有可能是别的osd本身数据有问题,backfill给这个osd之后,导致了这个osd的down?
可是,别的osd都不挂,就只有这个osd挂,而且,如果数据本身有问题,别的osd应该也早就发现了,不会现在才触发。
OK,那么如果数据是没有问题的,那么是盘有问题吗?os层面查了一圈,没有任何报错。
通过硬件专家的分析,盘,是ok的,没有异常。
那么就要开始松鼠哥的思路了(有猜测的成分),有没有可能盘是某个地方逻辑错误了,重建并不能处理这个错误,从而导致了持续的相同的问题?
在原盘上重建osd,首先是删除,松鼠哥采取的方法是通过lvremove
、vgremove
、pvremove
的方式对盘进行处理,删掉lvm后重新建立lvm,但是,这里有个细节,重新建立的lvm与原来的lvm名字完全相同(这是因为创建osd要按照一定的规则命名,便于管理),而删除lvm实际上只是在盘上将lvm的元数据信息清除,其他数据存放的地方是没有涉及清理的(这也给lvm的恢复提供可能性),也就是数据部分的存储空间实际上没有被清理,如果那些地方有数据或者有错误,自然也不会被清理。
为了验证猜想,松鼠哥使用dd对整块ssd盘进行全盘置0,强行将可能的逻辑错误清除,首先是检查盘的确切大小:
1 | [root@test-node-1 ceph]# parted /dev/sdh unit MiB print free |
显然它是915715MiB
的,以4MiB为单位,接下来用dd对盘进行低级格式化,也就是置0:
1 | [root@test-node-1 ceph]# dd if=/dev/zero of=/dev/sdh bs=4194304 count=228928 oflag=direct |
全盘置0所有的块都会跑到,所以要花点时间,不过是ssd的话速度很快。
完成后,对该盘重建osd,使用之前的lvm名字也能成功,跑观察了一段时间,数据恢复完成,没有见到报错了,说明低格有效。
1 | [root@test-node-1 ceph]# ps -ef|grep ceph-osd|grep 2263 |
总结
不敢说是不是dd全盘置0起的作用,但是确实这个osd通过这方法修好了。 如果有遇到类似情况且有其他思路的老铁,欢迎留言讨论~
- 本文作者: 奋斗的松鼠
- 本文链接: http://www.strugglesquirrel.com/2024/11/11/调查一个osd的rocksdb问题/
- 版权声明: 本博客所有文章除特别声明外,创作版权均为作者个人所有,未经允许禁止转载!