修复ceph集群状态异常

原创 已于 2023-10-08 10:05:28 修改 · 683 阅读 · 3 ·
CC 4.0 BY-SA版权
无
文章标签：

#ceph

于 2023-10-08 10:00:41 首次发布

ceph-2集群运行状态异常, 发生时间:2023.10.04 23:24:47,当前值为:HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistentOSD_SCRUB_ERRORS 1 scrub errorsPG_DAMAGED Possible data damage: 1 pg inconsistent    pg 1.d0f is active+clean+inconsistent, acting [221,41,134]

ceph health detail 获取出错的pg号，然后ceph pg repair  pg号，暂时修复一下。

经排查,ceph-2集群报错是因为osd.221硬盘坏道导致数据读取错误,需要把osd.221踢出集群.

ceph集群的pg卡住不同步处理记录【如objects degraded (0.223%)】、pg为unclean和degraded等状态处理
崔崇鑫的博客，你linux/云运维工作中的百科全书。
04-16 554
这条命令可以解决pg异常状态，后果我前面已经说过了。而且现在再此查看异常pg状态，发现都是显示的ok，证明没有异常pg。okokok。
ceph故障【pgs inconsistent；scrub errors】解决方法
李少阳的博客！
03-16 3423
ceph系统经常出现有问题的PG，有些能自动修复，有些一直报错。如下图 解决方法: 1 确定故障PG id ceph health detail 2 清洗恢复故障PG ceph pg repair PG-id 成功后，会告知成功与否，并显示所在OSD等信息 3 查看集群是否正常 ceph -s ceph osd dump
ceph修复pg inconsistent（ scrub errors）
a13568hki的博客
11-13 3548
集群出现pg状态变为 inconsistent 状态，inconsistent状态是pg通过scrub检测到某个或者某些对象在副本之间出现了不一致。找出异常的 pg，然后到对应的osd所在主机上修复。这里表示是主机intelligence-b-12。2.通过repair修复对应的pg。但是经过观察，并不能解决。4、修复（一般不需要）5、查看ceph的状态。
ceph pg inconsistent修复（unexpected clone）
卧龙居
08-03 2248
日志里：rbd_data.88033092ad95.0000000000000012:b : is an unexpected clone。9.处理完全部pg inconsistent后，清除其余标记位。b转为十进制为11，因此需要删除的为snapid为11的快照。pg 10.17 osd [3,4] 权威副本osd：3。6.启动osd（非权威副本）2.禁止recover。5.删除有问题的快照。重复处理完全部osd。
＜二十一＞搞不定 PG 不一致？Ceph 终极大法
最新发布
weixin_45645078的博客
10-10 1250
Ceph PG不一致及数据缺失问题处理指南 摘要：本文针对Ceph集群异常断电场景下常见的PG不一致(inconsistent)和数据缺失(unfound)问题，提供了系统化的解决方案。首先介绍了PG不一致问题的本质，即数据校验和异常。随后详细讲解了常规处理方法如深度检查和修复命令(ceph pg deep-scrub/repair)，以及当常规方法失效时的非常规处理流程。重点阐述了如何通过rados命令定位不一致对象，区分快照与数据问题，并提供了实际案例演示如何追踪问题对象到具体RBD卷。文末特别强调非常
ceph pg inconsistent
chitubuchitu的博客
12-29 1131
pg出现不一致，最简单的方法就是ceph health detail 然后根据pgid来ceph pg repair pgid 然后ceph -s检查一下，如果没有修复，那么就采用下一步 根据ceph pg map pgid,找到主osd,然后停止服务，冲洗日志，重启服务 # cd /var/log/ceph/ # grep -Hn 'ERR' /var/log/ceph/ceph-osd.63.log(这是查看日志报错的命令) systemctl stop ceph-osd@71.service ce.
ceph （ pgs inconsistent） pgs不一致 异常状态处理方式
weixin_34368949的博客
01-25 875
问题描述：在某些情况下，osd出现异常，导致pgs出现不一致状态# ceph health detailHEALTH_ERR 1 pgs inconsistent; 1 scrub errorspg 6.89 is active+clean+inconsistent, acting [12,1,10]1 scrub errors可以看到，pg 6.89处于不一致状态解决方式：...
Proxmox集群ceph报“ceph 1pg inconsistent”错误解决备忘
weixin_33726318的博客
12-08 389
故障描述Proxmox web管理界面监控状况“Ceph”变成由正常的绿色对勾（监控）变成红色严重错误警告！点进去以后，为“1pg inconsistent”. 处理措施登录集群任意一个节点，命令行执行root@pve48:~# ceph   health detailHEALTH_ERR 1 pgs   inconsistent; 1 scrub errors   pg 2.1ee is   a...
ceph集群维护常用操作
梵修
03-14 2896
在某一个osd故障后，需要将故障的osd更换为可用的osd，并将PG所对应的主osd上的数据同步到新的osd上，例如刚开始pg对应osd1、osd2和osd3，当osd3故障后需要用osd4替换osd3，那么osd1、osd2、osd3就是上行集，替换后osd1、osd2、osd4就是活动集，osd替换完成后活动集最终要替换上行集，即活动集和上行集要保持一致。就绪状态，Active表示主osd和备osd均处于正常状态，此时PG可以处理来自客户端的读写请求，正常的PG默认就是Active+Clean状态。
由于物理机异常宕机引起osd启动故障，引发ceph集群故障的修复
06-18 2106
某日凌晨，发现一个存储集群的4台存储节点(20个osd)宕机 发现是dell的四胞胎,初步排查是由于单个电源模块故障导致, 该机器存在的问题: 1:电源模块有故障 2:所有的盘做了单盘raid0的模式 3:机器已过保 4:raid卡电池推测已耗尽 5:使用了raid 缓存 异常宕机后导致的问题: 1:存在硬盘损坏 2:断电瞬间的缓存数据未写入磁盘 3:部分节点无法正常启动 4:部分osd节点无法自启 集群存储的问题 由于该集群为2副本,存储节点宕机比较多,宕机导...
Ceph的PG常见状态以及异常处理
bltyu2000的博客
03-27 1429
ceph的PG有几种状态。PG异常了怎么处理
Openstack 异常断电导致存储在ceph集群中的虚拟机起不来
supahero的博客
07-23 1135
原文链接：https://www.cpweb.top/1768 一、问题回顾 openstack 集群所有机器再经过一次异常断电后，存储在 ceph 集群中虚拟机起不来，ceph集群为双副本。 在断电之前关机的虚拟机是正常的，新建的虚拟机也正常。只有在断电时候处于运行的虚拟机是起不来的。 ceph集群状态： [root@controller ~]# ceph -s cluster: id: 6abf44d1-8ad2-4155-88db-8df0e79d576b h...
CEPH PG incomplete状态修复
a13568hki的博客
05-28 2104
某运营商的Kubernetes项目物理机停机维护，重启后Kubernetes部分pod无法挂载PVC，请求超时。该Kubernetes集群的后端存储使用ceph rbd块存储，检查ceph集群状态异常。集群检查提示PG_AVAILABILITY(数据可用性降低)，这说明群集无法满足群集中某些数据的潜在读取或写入请求。即有12个PG处于不允许为IO请求提供服务的状态。
如何解决Ceph集群中的数据不一致性和PG过载问题
博然的宝藏库
05-23 1440
如何解决Ceph集群中的数据不一致性和PG过载问题
ceph pg inconsistent不一致，ceph pg repair无效
流年似水的专栏
05-10 4601
指令执行后，无效原因分析 ceph pg repair这一操作会先进行pg scrub，得到该PG中不一致的对象，然后再进行recovery。 pg scrub时主副本和从副本均会进行资源预约，只有当scrubs_pending + scrubs_active < cct->_conf->osd_max_scrubs时scrub才能继续进行，也即repair才能进行，否则，r...
ceph （ pgs inconsistent） pgs不一致 异常状态问题
dcwnb1的专栏
03-16 2906
现象：巡检ceph时候$ ceph health detailHEALTH_ERR 1 pgs inconsistent; 1 scrub errorspg 4.395 is active+clean+inconsistent, acting [37,278,197]1 scrub errors解决方法：进行修复$ ceph pg repair 4.395instructing pg 4.395 ...
（7）ceph 2 pgs inconsistent故障
binge6687的博客
09-02 1760
[root@node141 ~]# ceph health detailHEALTH_ERR 2 scrub errors; Possible data damage: 2 pgs inconsistentOSD_SCRUB_ERRORS 2 scrub errorsPG_DAMAGED Possible data damage: 2 pgs inconsistentpg 3.3e is acti...
ceph修复pg inconsistent
weixin_34123613的博客
04-04 1734
异常情况 1、收到异常情况如下: HEALTH_ERR 37 scrub errors; Possible data damage: 1 pg inconsistent 2、查看详细信息 #ceph health detail HEALTH_ERR 37 scrub errors; Possible data damage: 1 pg inconsistent OSD_SCRUB_ERRORS 3...
ceph 的pg诊断
weixin_34025051的博客
02-10 861
2019独角兽企业重金招聘Python工程师标准>>> ...
active+remapped+backfilling状态时能再向ceph集群添加新硬盘
08-30
<think> 嗯，用户询问在Ceph集群处于active+remapped+backfilling状态时能否添加新硬盘。这是一个关于Ceph存储集群运维的具体技术问题。 从提供的引用内容来看，有几个关键点需要注意。引用[1]和[3]都显示集群出现PG状态异常，特别是active+remapped+backfilling这种组合状态，表明集群正在进行数据重映射和回填操作。引用[2]提到当无法根据PGLog恢复数据时需要执行全量回填。引用[5]则记录了在存在remapped pgs的情况下集群仍在正常运行。 用户可能正在管理一个出现数据迁移问题的Ceph集群，同时想要扩容存储空间。虽然看似是两个独立操作，但它们都涉及集群数据重分布。深层需求可能是想在保证业务连续性的情况下安全扩容。 技术上分析，active+remapped+backfilling状态说明集群正处于自我修复过程中。添加新硬盘会触发CRUSH算法重新计算数据分布，可能加剧集群负载。引用[2]提到osd_max_pg_log_entries参数影响恢复方式，暗示恢复过程对资源敏感。 最关键的判断依据是：添加硬盘操作本身不会受阻，但需要评估当前集群负载能力。引用[3]显示在类似状态下集群仍有24TB可用空间，说明监控指标很重要。建议用户添加硬盘前先检查恢复进度和系统负载，避免雪崩效应。 操作层面给出分步指引：先确认恢复状态，再添加硬盘，最后监控合并影响。特意强调要避免在高峰期操作，因为引用[1]显示拆盘操作会触发OSD重建，类似操作可能相互干扰。 考虑到用户能提供详细的PG状态信息，应该是具备基础运维能力的。但问题中未提及集群规模和数据量，所以在建议里加入了负载评估环节。对于高级用户，其实可以进一步讨论并行操作的优化策略，但当前回答保持普适性更安全。 </think> 在Ceph集群处于`active+remapped+backfilling`状态时**可以添加新硬盘**，但需谨慎操作并遵循以下原则： ### 关键技术分析 1. **状态本质说明** `active+remapped+backfilling`表示： - **PG正在重新映射**：OSD布局因节点/磁盘变动发生调整（如引用[1][3]中RAID0拆分或OSD重启） - **数据回填中**：集群正根据CRUSH规则将数据迁移至新位置（引用[2][3]） - **集群仍可用**：`active`状态表明数据访问不受影响（引用[5]） 2. **添加硬盘的影响** ```mermaid graph LR A[添加新硬盘] --> B[触发OSD扩容] B --> C[CRUSH重新计算数据分布] C --> D[新增PG迁移任务] D --> E{与现有backfill任务并发} E -->|资源充足| F[正常完成扩容] E -->|资源过载| G[延长恢复时间] ``` ### 操作建议（分步执行） 1. **优先处理现有异常状态** - 检查回填进度：`ceph -s` 观察`backfilling` PG数量变化（引用[3]） - 确认恢复瓶颈：`ceph osd perf` 查看OSD延迟，若存在高延迟OSD需优先处理 - 参考引用[2]方案：确保未触发`osd_max_pg_log_entries`阈值导致全量回填 2. **安全添加硬盘流程** ```bash # 1. 暂停集群自动恢复（避免资源争抢） ceph osd set norecover ceph osd set nobackfill # 2. 添加新硬盘并创建OSD ceph-volume lvm create --data /dev/sdX # 替换为新硬盘路径 # 3. 观察集群稳定后再恢复操作（引用[5]） ceph osd unset norecover ceph osd unset nobackfill ``` 3. **关键监控指标** - **回填速度**：`ceph -s`中`misplaced`对象下降速率 - **OSD负载**：`iostat -x 1` 检查新老硬盘IO利用率 - **网络负载**：`iftop` 监控跨节点流量避免拥塞 ### 风险规避措施 - **避免高峰操作**：在业务低峰期执行扩容（引用[3]显示`remapped`期间已有性能影响） - **分批添加硬盘**：若需添加多块盘，建议间隔30分钟以上（根据`backfilling`完成速度调整） - **优先修复旧PG**：当`HEALTH_WARN`中异常PG>5时（引用[2][3]），应推迟扩容直至降至安全水平 > **结论**：添加操作本身不会阻断，但可能延长现有`backfilling`时间。建议先通过`ceph health detail`（引用[2]）确认当前恢复压力，若存在`stuck unclean`等严重状态（引用[2] 3.6节），需优先排除基础故障再扩容[^1][^2][^3]。 --- ### 相关问题 1. Ceph集群处于`active+remapped`状态时数据访问是否受影响？ 2. 如何加速PG的`backfilling`过程？ 3. `norecover`标志位对数据恢复有哪些限制？ 4. 添加新OSD后如何验证CRUSH规则是否生效？ [^1]: RAID0拆分导致OSD重建触发remapped [^2]: Backfill阈值超过osd_max_pg_log_entries时需全量恢复 [^3]: remapped+backfilling状态伴随misplaced对象迁移
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值