Ceph: Manually Repair Object

本文由 Ceph中国社区-半天河翻译,高华敏 校稿。

英文出处:Sébastien Han 欢迎加入 翻译组

ceph-manually-repair-objects

调试scrub错误有窍门,你甚至无需了解调试究竟是怎样进行的。

假设你的集群状态信息类似下面这样:

health HEALTH_ERR 1 pgs inconsistent; 2 scrub errors

现在让我们开始对故障进行排错吧。

定位PG

用下面这条简单的命令找到出问题的PG:

$ sudo ceph health detail
HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 17.1c1 is active+clean+inconsistent, acting [21,25,30]
2 scrub errors

由上可知,出问题的PG是17.1c1,该PG的acting OSD是21、25和30。

你可以尝试运行ceph pg repair 17.1c1,然后检查问题是否得以修复。这条命令有时可行,但如果不能修复故障的话,你就得深挖。

定位故障

为了找到故障的根本起因,我们需要到OSD的日志文件里仔细看看。使用这个简单命令:grep -Hn ‘ERR’ /var/log/ceph/ceph-osd.21.log,注意,如果日志文件是循环写入的,你需要使用zgrep替代grep

日志中的这段话显示了故障的根本起因:

log [ERR] : 17.1c1 shard 21: soid 58bcc1c1/rb.0.90213.238e1f29.00000001232d/head//17 digest 0 != known digest 3062795895
log [ERR] : 17.1c1 shard 25: soid 58bcc1c1/rb.0.90213.238e1f29.00000001232d/head//17 digest 0 != known digest 3062795895

这段日志说明了什么?
它表明,object digest应该是3062795895,而现在却是0 。

定位object

现在我们不得不到OSD.21目录里看看,多亏我们现已掌握的信息,它们已经相当直白:

  • 故障PG:17.1c1
  • OSD编号:21、25,30
  • Object名字:rb.0.90213.238e1f29.00000001232d()

现在,我们搜索这个object:

$ sudo find /var/lib/ceph/osd/ceph-21/current/17.1c1_head/ -name ‘rb.0.90213.238e1f29.00000001232d*’ -ls
671193536 4096 -rw-r–r– 1 root root 4194304 Feb 14 01:05 /var/lib/ceph/osd/ceph-21/current/17.1c1_head/DIR_1/DIR_C/DIR_1/DIR_C/rb.0.90213.238e1f29.00000001232d__head_58BCC1C1__11

还有一些其他事项需要检查:

  • 查看PG每个acting OSD上该object的大小
  • 查看PG每个acting OSD上该object的MD5

检查之后,对比所有这些object,找到出故障的那个object。

修复故障

按照下面的方法移除故障object即可:

  • 停止故障object所在的OSD
  • flush日志( ceph-osd -i <id> –flush-journal
  • 将出故障的object移到别的地方
  • 重新启动OSD服务
  • 执行命令 ceph pg repair 17.1c1

 

直接删除object看起来有些粗暴,但最终是由Ceph job做了一些工作。在有三个副本的情况下,以上方法显然能够正常使用,因为将其中两个版本和另一个版本进行对比是相当容易的。但如果只有2个副本,情况则有些不同。Ceph可能因无法解决版本冲突,导致故障依然存在。所以,一个简单的窍门是,选择一个最新版本的object,在集群上将其标记为 noout,停掉有错误版本object的OSD,稍等片刻后,重启OSD,并取消之前设置在最新版object上的noout标记。这时,集群就会将正确版本的object同步到有错误版本object的OSD。

Leave a Comment

电子邮件地址不会被公开。