拯救EC存储池数据

2023-12-05

字数统计: 1.7k字 | 阅读时长≈ 6分

读者朋友遇到的问题

写在前面

松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧联系松鼠哥订购吧：

松鼠哥组建的微信群已经超过了200人，目前已经没法扫码加入了，请有意向进群的老铁加松鼠哥微信再拉进去。

本篇是一位群友遇到的问题，EC存储池pg出问题，一番操作救回了数据，征得其同意后写出来给大家参考。

其实关于EC存储池PG的修复内容，本公众号前面有所涉及，不过没有那么正式，也不完全一样，其中《修复一个纸糊的集群》介绍的是丢弃整个PG ，重新创建的方式，而《bluestore拯救pg》则是OSD无法启动，备份PG导入导出的方式，与今天要介绍的情况有点不同。

目标版本是17.2.6，容器化部署，比较新

问题的出现

群友的环境中，存储池使用EC 4+1，故障域host，这个配置，我看了也得点赞！

经历了如下过程：

1、集群缩容，减少2台机器，直接在dashboard的页面上点的Drain
2、过了一段时间，发现集群不可读写了
3、经过排查，发现缩容的2台机器挂掉了
4、再等，发现osd.5 down状态且out
5、集群出现pg inactive，incomplete，集群不可读写

看完过程已经很清楚了，缩容EC 4+1的池，页面点击Drain(不知道它是怎么缩法，应该就是out出集群)，在数据未完全恢复时，两台机器挂掉了，导致pg无法凑齐足够的分片。

dashboard提供的功能，真的不能随便用啊~~有危险的操作必须是后台慢慢来稳妥。

问题的排查

没什么好排查的，怀疑是分片不够了， ceph pg 4.71 query看了下incomplete状态的pg，日志是这么说的

"down_osds_we_would_probe":[
                   5
                   303
                   478
"peering_blocked by":[]
"peering_blocked by_detail":[
"detail":
    "peering_blocked_by_history_les _bound"
"name":"Started"'enter_time":"2023-10-07T06:39:46.771351+0000"
"agent_state":()
]

peering_blocked_by_history_les _bound说得很清楚了，blocked是因为分片不够。

既然是分片不够导致数据没法恢复，主要思路是两个：

1、放弃这个PG，重建，让集群恢复正常
2、想办法凑齐k个分片

事实上，对于新手朋友来说，放弃这个PG是最先考虑的做法，因为集群有pg incomplete 状态，所有与这个pg相关的op都会卡住，无法读写，越是这样的情况，就越希望快速恢复集群读写能力，宁愿放弃这个PG的数据。

这里要提醒一点，重建这个PG不仅仅是放弃这个PG的数据，拿这个环境来说，存储池跑了cephfs，且都是大文件(GiB级别)，这就是说，每一个文件会有非常多数据会分布到这个PG上，任何一份数据丢失都会导致这个文件在客户端无法正常读写，这就不仅仅影响单个PG几十G数据那么简单，所以不到万不得已，千万不要有重建PG 的想法，只要还有一线希望就应该保护数据。

在此环境中，osd.5 down掉是因为坏盘，但是另外2台机器缩容out出集群，它们的数据应该是没有丢失的，在PG backfilling过程中，只要PG没有完全迁移完成，原来osd上的PG是不会删除的，这是ceph对数据可靠性的强制保护机制，所以，我们可以考虑将挂掉的2台机器拉起来，将所需要的PG导出来，导入到新的OSD中，恢复k个分片。

问题解决

当前故障pg是4.71，pgmap显示

1 2	ceph pg map 4.71 osdmap e96684 g 4.71 (4.71) -> up [204,397,18,315,131] acting [204,397,18,315,131]

从前面可知，考虑到osd.5是坏盘，有可能找不到数据了，我们需要从osd.303和osd.478中导出这个pg 4.71的分片，然后导入到对应的osd中即可。

所幸挂掉的机器中，osd.478和osd.303都找到了这个PG的分片

osd.478上查到pg的分片
[root@~]# ceph-objectstore-tool --data-path /var/lib/ceph/xxx --type bluestore --op list-pgs|grep '4.71' --no-mon-config
4.71s1

osd.303上查到pg的分片
[root@~]# ceph-objectstore-tool --data-path /var/lib/ceph/xxx --type bluestore --op list-pgs|grep '4.71' --no-mon-config
4.71s3

接下来，分别导出这两个分片

1
2

ceph-objectstore-tool --data-path /var/lib/ceph/xxx --type bluestore --pgid 4.71s1 --op export --file 4.71s1.pgdata --no-mon-config
ceph-objectstore-tool --data-path /var/lib/ceph/xxx --type bluestore --pgid 4.71s1 --op export --file 4.71s3.pgdata --no-mon-config

然后，怎么导入呢？因为现在pg已经完成了remapped，所以我们要将pg手工导入到新的osd中，搞一下对应关系

1 2	pg s0 s1 s2 s3 s4 osd 204 397 18 315 131

根据对应关系，4.71s1应该要导入到osd.397，而4.71s3则导入到osd.315，然后markcomplete

ceph-objectstore-tool --data-path /var/lib/ceph/xxx --type bluestore --pgid 4.71s1 --op import --file 4.71s1.pgdata --no-mon-config
ceph-objectstore-tool --data-path /var/lib/ceph/xxx --type bluestore --pgid 4.71s1 --op mark-complete

ceph-objectstore-tool --data-path /var/lib/ceph/xxx --type bluestore --pgid 4.71s3 --op import --file 4.71s3.pgdata --no-mon-config
ceph-objectstore-tool --data-path /var/lib/ceph/xxx --type bluestore --pgid 4.71s3 --op mark-complete

注意，在操作中，如果目标osd已经存在了该pg，则可能出现无法导入的情况，这时需要先备份导出这个osd上的对应pg，然后删除，再重新导入

1	ceph-objectstore-tool --data-path /var/lib/ceph/xxx --type bluestore --pgid 4.71s3 --op remove --force

这样就可以了

一番操作之后，pg成功修复，老铁反馈，仅十来个文件出错，绝大部分数据完好。

总结

说实话，新版本集成的一些功能，如果不是很了解它的运作原理的话，操作起来其实是有一定的危险性的。

就拿本篇例子缩容来说，稳妥一点的缩容操作应该是先降低恢复速度，out一台出集群，恢复完再out下一台，更保守点就几个osd慢慢来，而不是一把梭。

总的来说ceph的运维运营最好还是在后台，搞清楚原理和操作，再下手，毕竟数据无价啊。

pg级别的操作，在本公众号不少文章都有，算是比较硬核的内容了，一般来说不是灾难性场景也用不到，不过学会了有备无患。

本文作者： 奋斗的松鼠
本文链接： http://www.strugglesquirrel.com/2023/12/05/拯救EC存储池数据/
版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！