今天检查ceph集群,发现有pg丢失,于是就有了本文~~~

1.查看集群状态

[root@k8snode001 ~]# ceph health detail
HEALTH_ERR 1/973013 objects unfound (0.000%); 17 scrub errors; Possible data damage: 1 pg recovery_unfound, 8 pgs inconsistent, 1 pg repair; Degraded data redundancy: 1/2919039 objects degraded (0.000%), 1 pg degraded
OBJECT_UNFOUND 1/973013 objects unfound (0.000%)
pg 2.2b has 1 unfound objects
OSD_SCRUB_ERRORS 17 scrub errors
PG_DAMAGED Possible data damage: 1 pg recovery_unfound, 8 pgs inconsistent, 1 pg repair
pg 2.2b is active+recovery_unfound+degraded, acting [14,22,4], 1 unfound
pg 2.44 is active+clean+inconsistent, acting [14,8,21]
pg 2.73 is active+clean+inconsistent, acting [25,14,8]
pg 2.80 is active+clean+scrubbing+deep+inconsistent+repair, acting [4,8,14]
pg 2.83 is active+clean+inconsistent, acting [14,13,6]
pg 2.ae is active+clean+inconsistent, acting [14,3,2]
pg 2.c4 is active+clean+inconsistent, acting [8,21,14]
pg 2.da is active+clean+inconsistent, acting [23,14,15]
pg 2.fa is active+clean+inconsistent, acting [14,23,25]
PG_DEGRADED Degraded data redundancy: 1/2919039 objects degraded (0.000%), 1 pg degraded
pg 2.2b is active+recovery_unfound+degraded, acting [14,22,4], 1 unfound

从输出发现pg 2.2b is active+recovery_unfound+degraded, acting [14,22,4], 1 unfound

现在我们来查看pg 2.2b,看看这个pg得想想信息。

[root@k8snode001 ~]# ceph pg dump_json pools    |grep 2.2b
dumped all
2.2b 2487 1 1 0 1 9533198403 3048 3048 active+recovery_unfound+degraded 2020-07-23 08:56:07.669903 10373'5448370 10373:7312614 [14,22,4] 14 [14,22,4] 14 10371'5437258 2020-07-23 08:56:06.637012 10371'5437258 2020-07-23 08:56:06.637012 0

可以看到它现在只有一个副本

2.查看pg map

[root@k8snode001 ~]# ceph pg map 2.2b
osdmap e10373 pg 2.2b (2.2b) -> up [14,22,4] acting [14,22,4]

从pg map可以看出,pg 2.2b分布到osd [14,22,4]上

3.查看存储池状态

[root@k8snode001 ~]# ceph osd pool stats k8s-1
pool k8s-1 id 2
1/1955664 objects degraded (0.000%)
1/651888 objects unfound (0.000%)
client io 271 KiB/s wr, 0 op/s rd, 52 op/s wr [root@k8snode001 ~]# ceph osd pool ls detail|grep k8s-1
pool 2 'k8s-1' replicated size 3 min_size 1 crush_rule 0 object_hash rjenkins pg_num 256 pgp_num 256 last_change 88 flags hashpspool,selfmanaged_snaps stripe_width 0 application rbd

4.尝试恢复pg 2.2b丢失的块

[root@k8snode001 ~]# ceph pg repair 2.2b

如果一直修复不成功,可以查看卡住PG的具体信息,主要关注recovery_state,命令如下

[root@k8snode001 ~]# ceph pg 2.2b  query
{
"......
"recovery_state": [
{
"name": "Started/Primary/Active",
"enter_time": "2020-07-21 14:17:05.855923",
"might_have_unfound": [],
"recovery_progress": {
"backfill_targets": [],
"waiting_on_backfill": [],
"last_backfill_started": "MIN",
"backfill_info": {
"begin": "MIN",
"end": "MIN",
"objects": []
},
"peer_backfill_info": [],
"backfills_in_flight": [],
"recovering": [],
"pg_backend": {
"pull_from_peer": [],
"pushing": []
}
},
"scrub": {
"scrubber.epoch_start": "10370",
"scrubber.active": false,
"scrubber.state": "INACTIVE",
"scrubber.start": "MIN",
"scrubber.end": "MIN",
"scrubber.max_end": "MIN",
"scrubber.subset_last_update": "0'0",
"scrubber.deep": false,
"scrubber.waiting_on_whom": []
}
},
{
"name": "Started",
"enter_time": "2020-07-21 14:17:04.814061"
}
],
"agent_state": {}
}

如果repair修复不了;两种解决方案,回退旧版或者直接删除

5.解决方案

回退旧版
[root@k8snode001 ~]# ceph pg 2.2b mark_unfound_lost revert
直接删除
[root@k8snode001 ~]# ceph pg 2.2b mark_unfound_lost delete

6.验证

我这里直接删除了,然后ceph集群重建pg,稍等会再看,pg状态变为active+clean

[root@k8snode001 ~]#  ceph pg  2.2b query
{
"state": "active+clean",
"snap_trimq": "[]",
"snap_trimq_len": 0,
"epoch": 11069,
"up": [
12,
22,
4
],

再次查看集群状态

[root@k8snode001 ~]# ceph health detail
HEALTH_OK

记一次ceph pg unfound处理过程的更多相关文章

  1. ceph PG数量调整/PG的状态说明

    优化: PG Number PG和PGP数量一定要根据OSD的数量进行调整,计算公式如下,但是最后算出的结果一定要接近或者等于一个2的指数.调整PGP不会引起PG内的对象的分裂,但是会引起PG的分布的 ...

  2. Ceph PG介绍及故障状态和修复

    1 PG介绍pg的全称是placement group,中文译为放置组,是用于放置object的一个载体,pg的创建是在创建ceph存储池的时候指定的,同时跟指定的副本数也有关系,比如是3副本的则会有 ...

  3. 解Bug之路-记一次存储故障的排查过程

    解Bug之路-记一次存储故障的排查过程 高可用真是一丝细节都不得马虎.平时跑的好好的系统,在相应硬件出现故障时就会引发出潜在的Bug.偏偏这些故障在应用层的表现稀奇古怪,很难让人联想到是硬件出了问题, ...

  4. 利用火焰图分析ceph pg分布

    前言 性能优化大神Brendan Gregg发明了火焰图来定位性能问题,通过图表就可以发现问题出在哪里,通过svg矢量图来查看性能卡在哪个点,哪个操作占用的资源最多 在查看了原始数据后,这个分析的原理 ...

  5. Ceph pg分裂流程及可行性分析

    转自:https://www.ustack.com/blog/ceph-pg-fenlie/ 1 pg分裂 Ceph作为一个scalable的分布式系统,集群规模会逐渐增大,为了保证数据分布的均匀性, ...

  6. 记一次ceph的故障修复(20160408)

    ceph的在正常运行的时候基本不会出现故障,出现故障一般在变动的时候,具体有下面几种可能出现的情形 软件升级 增加存储节点 减少存储节点 调整副本数目 调整pg数目 磁盘出现损坏 节点网络出现异常 以 ...

  7. 在Ceph创建虚拟机的过程改进分析

    作为个人学习笔记分享.有不论什么问题欢迎交流! 近期在Gerrit中看到一个change:https://review.openstack.org/#/c/94295/ , 它主要是对当前在Ceph中 ...

  8. [转] 关于 Ceph PG

    本系列文章会深入研究 Ceph 以及 Ceph 和 OpenStack 的集成: (1)安装和部署 (2)Ceph RBD 接口和工具 (3)Ceph 物理和逻辑结构 (4)Ceph 的基础数据结构 ...

  9. 记一次ceph集群的严重故障

    问题:集群状态,坏了一个盘,pg状态好像有点问题[root@ceph-1 ~]# ceph -s    cluster 72f44b06-b8d3-44cc-bb8b-2048f5b4acfe     ...

随机推荐

  1. Docker 部署 _实现每日情话 定时推送(apscheduler)

    由于最近工作比较忙,后续博客可能更新不及时,哈哈 前言: 由于python对于微信推送不够友好,需要扫码登录,短信接口需要RMB.我就想到了qq邮箱发送到好友,然而微信有qq邮箱提醒功能,就实现了我需 ...

  2. 微服务 - 服务消费(七)Feign

    介绍 Spring Cloud Feign是一套基于Netflix Feign实现的声明式服务调用客户端.它使得编写Web服务客户端变得更加简单.我们只需要通过创建接口并用注解来配置它既可完成对Web ...

  3. 使用@Cacheable注解时,Redis连不上,直接调用方法内部的解决方案

    最近redis 域名一致解析错误,导致业务多了很多异常.那么如何在这种情况下直接访问数据库,而不是报错呢 1. 解决方案 其实很简单,在配置 redis 时,只需要多一项配置,继承 CachingCo ...

  4. easyui框架 jsp页面

    <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding= ...

  5. Java中几种常见的循环

    多重if_else: package com.dengchaoqun.ht; public class Double_For02 { /** * * 打印乘法表 */ public static vo ...

  6. redis基础-Remote Dictionary Server

    Redis支持多个数据库,并且每个数据库的数据是隔离的不能共享,并且基于单机才有,如果是集群就没有数据库的概念. Redis默认支持16个数据库(可以通过配置文件支持更多,无上限),可以通过配置dat ...

  7. Flask 操作Mysql数据库 - flask-sqlalchemy扩展

    数据库的设置 Web应用中普遍使用的是关系模型的数据库,关系型数据库把所有的数据都存储在表中,表用来给应用的实体建模,表的列数是固定的,行数是可变的.它使用结构化的查询语言.关系型数据库的列定义了表中 ...

  8. netcore项目中使用 SpringCloudConfig 和apollo做配置中心

    版权所有,转载请注明出处 https://www.cnblogs.com/netqq/p/14251403.html 一.使用apollo作为配置中心 首先apollo 项目简介和安装请自行百度,本文 ...

  9. 如何在Linux(CentOS7)环境搭建 Jenkins 服务器环境

    最近,我自己要亲手搭建一套完整的企业级 CI/CD 环境,这个环节里面涉及了很多内容,没有办法把这么多的内容都放在一篇文章里,所以 Jenkins 的安装和Java 的 JDK 安装我就是分了两篇文章 ...

  10. 神经网络中的降维和升维方法 (tensorflow & pytorch)

    大名鼎鼎的UNet和我们经常看到的编解码器模型,他们的模型都是先将数据下采样,也称为特征提取,然后再将下采样后的特征恢复回原来的维度.这个特征提取的过程我们称为"下采样",这个恢复 ...