mds.0 is damaged

mds rank 0 is damaged

某次机房断电后，再启动ceph后，出现如下错误：

[root@k8s-node2 ~]# ceph health detail
HEALTH_ERR mds rank 0 is damaged; mds cluster is degraded
mds.0 is damaged
mds cluster is degraded

提示 mds.0 不可用。在部署ceph时，安装了3个mds, 分别运行在3台服务器上。并且参考官方的配置，使其中一个作为 master 对外提供服务，另外两个作为 standby。来预防单点故障。(max_mds 设置为 2)

http://docs.ceph.com/docs/jewel/cephfs/standby/#examples

该错误发生后，3 个mds，均为 standby 状态。按照官网的描述来看，当所有 mds 均处于 standby 状态时，其中一个 mds 会选举称为 master.

于是挨个停止mds, 随后又逐个启动并查看/var/log/ceph/ceph-mds.xx.log。发现 mds 在称为 master 时，出现了如下错误：

...2017-09-26 11:30:48.976326 7f9ee3941700  0 mds.0.journaler(ro) _finish_read got less than expected (4194304)
2017-09-26 11:30:48.976354 7f9ee1734700  0 mds.0.log _replay journaler got error -22, aborting
2017-09-26 11:30:49.071230 7f9ee3941700  0 mds.0.journaler(ro) _finish_read got less than expected (4194304)
2017-09-26 11:30:49.071472 7f9ee1734700 -1 log_channel(cluster) log [ERR] : Error loading MDS rank 0: (22) Invalid argument
2017-09-26 11:30:49.076129 7f9ee1734700  1 mds.k8s-node1 respawn...2017-09-26 11:30:49.099291 7f99e58be180  0 pidfile_write: ignore empty --pid-file
2017-09-26 11:30:49.571643 7f99dfacf700  1 mds.k8s-node1 handle_mds_map standby

提示在读取 journal 的时候出现差错，因此可以确定问题出在 mds journal 上。

通过 google 也查到过一些类似的 issue, 大致解决办法是执行：

$ ceph mds repaire 0

并重启各个 mds daemon, 但该方式并不适用此问题。最终参考官方的故障恢复部分章节得以解决：

http://docs.ceph.com/docs/jewel/cephfs/disaster-recovery/

步骤如下(译自上述文档)：

1. 导出 journal

在执行有风险的操作之前，先将 journal 备份：

$ ceph-journal-tool journal export backup.bin

Note : 这个文件大小和ceph集群存储数据量成正比，会很大

2. 从 journal 恢复

当 mds 因为 journal 损坏或者其他原因无法读取，为了恢复文件元数据可以执行：

$ ceph-journal-tool event recover_dentries summary

默认会从 mds.0 中恢复, 使用 --rank=<n> 来指定其他mds

这条指令会将 journal 中所有可回收的 inodes/dentries 写到后端存储，前提是要写入的 innodes/dentries 版本比后端存储里面的要高。如果某个区块的 journal 丢失或者损坏，那么就不会被写到后端存储中。

Note : 除了将inodes/dentries 写入之外，这条命令还会更新每个 MDS 的 InoTables, 标明被写入的 inodes 号在使用中，在一般情况下，会让后端存储恢复正常状态。

Warning : 此操作不能保证后端存储的状态达到前后一致，而且在此之后有必要执行 MDS 在线 scrub。此命令不会更改日志内容，恢复了能恢复的部分后应该把journal截短。

Note : 然而在执行这个命令之后，集群并未恢复正常，因此还需要往下看

3. 截断日志

$ cephfs-journal-tool journal reset

Warning : 重置journal 将会造成metadata丢失，除非你提前通过诸如 recover_dentries 的方式将metadata保存。该操作可能会在数据池里面产生一些孤儿对象。这会造成已写入的inodes再次被重新分配，权限规则可能因此被违反。

Note : 有个类似的 issue中也提到了上述步骤（link）,但执行到这一步后，就没往下走了。
And mds rejoined again and everything seems to work fine now. 这点我没验证过，担心会有隐患。于是按照文档步骤继续执行了。

4. 清除 MDS 表

在 journal 被 reset 之后，它可能不再符合MDS表的内容（包括：InoTable, SessionMap, SnapServer）. 重置 SessionMap (即擦除所有Session) , 通过命令：

$ cephfs-table-tool all reset session

这条命令会在所有mds中生效，可以将 all 替换为指定 mds 标号。

5. MDS MAP RESET

一旦文件系统底层的 RADOS 状态（即元数据存储池的内容）有所恢复，有必要更新 MDS 图以反映元数据存储池的内容。可以用下面的命令把 MDS MAP 重置到单个 MDS ：

$ ceph fs reset <fs name> --yes-i-really-mean-it

运行此命令之后， MDS rank 保存在 RADOS 上的任何不为 0 的状态都会被忽略：因此这有可能导致数据丢失。

也许有人想知道 fs reset 和 fs remove; fs new 的不同。主要区别在于，执行删除、新建操作会使 rank 0 处于 creating 状态，那样会覆盖所有根索引节点、并使所有文件变成孤儿；相反， reset 命令会使 rank 0 处于 active 状态，这样下一个要认领此 rank 的 MDS 守护进程会继续、并使用已存在于 RADOS 中的数据。

Note : fs name 可通过 ceph fs ls 查看

6. RECOVERY FROM MISSONG METADATA OBJECT

# Session table
cephfs-table-tool 0 reset session
# SnapServer
cephfs-table-tool 0 reset snap
# InoTable
cephfs-table-tool 0 reset inode
# Journal
cephfs-journal-tool --rank=0 journal reset
# Root inodes ("/" and MDS directory)
cephfs-data-scan init

最后，会基于数据池中丢失的文件和目录来重新创建 METADATA OBJECT。分为2步。

扫描所有对象并计算出inodes 的大小和 mtime metadata
```
$ cephfs-data-scan scan_extents <data pool>
```
扫描每个文件中的第一个对象来收集METADATA，随后注入到 metadata pool
```
$ cephfs-data-scan scan_inodes <data pool>
```

Note : 这两个步骤太耗时了，应该考虑起多个workers来同步处理。data pool 可通过 ceph fs ls 查看

# Worker 0
cephfs-data-scan scan_extents <data pool> 0 1
# Worker 1
cephfs-data-scan scan_extents <data pool> 1 1# Worker 0
cephfs-data-scan scan_inodes <data pool> 0 1
# Worker 1
cephfs-data-scan scan_inodes <data pool> 1 1

==Note : 一定要确保在所有 workers 完成 scan_extents 之后再进行scan_inodes操作。==

待所有操作执行完毕之后：

[root@k8s-master ~]# ceph -scluster e61d687d-f43d-4f50-af66-da96e5856be9health HEALTH_OKmonmap e5: 3 mons at {k8s-master=172.16.18.30:6789/0,k8s-node1=172.16.18.6:6789/0,k8s-node2=172.16.18.7:6789/0}election epoch 676, quorum 0,1,2 k8s-node1,k8s-node2,k8s-masterfsmap e4970: 1/1/1 up {0=k8s-node1=up:active}, 2 up:standbyosdmap e2914: 6 osds: 6 up, 6 inflags sortbitwise,require_jewel_osdspgmap v10110565: 256 pgs, 4 pools, 25575 MB data, 372 kobjects58730 MB used, 11115 GB / 11172 GB avail256 active+clean

集群恢复正常！

mds.0 is damaged相关推荐

HEALTH_WARN mds 0 is laggy的解决方法
当你的ceph集群状态遇到如下状态时, $ ceph -s cluster 3a4399c0-2458-475f-89be-ff961fbac537 health HEALTH_WA ...
mds is damaged
问题:有可能节点内存被某进程耗尽,造成多fs的某个mds 损坏 #ceph health detail HEALTH_ERR mds rank 0 is damaged; mds cluster is ...
ceph mds dmaged造成cephfs崩掉的灾难性恢复
**问题:**未知原因,有可能是服务器搬离机柜造成的.也有可能是osd crash出错,数据丢失,cephfs无法提供服务,经查,是没有active的mds了,所有的mds都是standby状态,并且 ...
【ceph】ceph分布式存储MDS(各种状态、源码)
目录 1. mds存储 2. mds冷备/热备 3. mds主备切换策略 4. 节点失效机制 5. 恢复过程 6. resolve阶段的事件 7. 重建分布式缓存和锁状态 Ceph MDS State ...
CephFS MDS服务高可用
Ceph mds(metadata service)作为 ceph 的访问入口,需要实现高性能及数据备份,假设启动 4 个 MDS 进程,设置 2 个 Rank.这时候有 2 个 MDS 进程会分配给 ...
【ceph】ceph osd blacklist cep黑名单|MDS问题分析
目录 blacklist 是什么 blacklist相关操作 Ceph MDS问题分析 CephFS client evict子命令使用概述命令格式 1. 查看所有client/session 2 ...
Ceph MDS问题分析
1. 问题背景 1.1 客户端缓存问题 $ ceph -s health HEALTH_WARN mds0: Client xxx-online00.gz01 failing to respond t ...
从ceph集群中删除MDS server
2019独角兽企业重金招聘Python工程师标准>>> 如果你不需要cephfs,MDS就成了多余的.为了提高性能,可以把MDS卸载掉. 首先停止所有的MDS daemon: $ s ...
估算带卷积核二分类0,3的网络的收敛时间和迭代次数
制作一个网络分类minst的0和3求出这网络的迭代次数曲线表达式n(δ),和准确率表达式p-max(δ),用预期准确率去估算n,并推算需要的时间. 将minst的28*28的图片缩小到9*9,网络用一 ...