当前位置:首页 >焦点 >记一次Ceph pg unfound处理过程 [[379685]] 今天检查ceph集群

记一次Ceph pg unfound处理过程 [[379685]] 今天检查ceph集群

2024-06-30 17:09:18 [百科] 来源:避面尹邢网

记一次Ceph pg unfound处理过程

作者:老实说运维 运维 系统运维 今天检查ceph集群,记次发现有pg丢失,处程本文就给大家介绍一下解决方法。

[[379685]]

 今天检查ceph集群,理过发现有pg丢失,记次于是处程就有了本文~~~

记一次Ceph pg unfound处理过程 [[379685]] 今天检查ceph集群

1.查看集群状态

记一次Ceph pg unfound处理过程 [[379685]] 今天检查ceph集群

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

记一次Ceph pg unfound处理过程 [[379685]] 今天检查ceph集群

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

  1. [root@k8snode001 ~]# ceph pg dump_json pools    |grep 2.2b 
  2. dumped all 
  3. 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

  1. [root@k8snode001 ~]# ceph pg map 2.2b 
  2. 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.查看存储池状态

  1. [root@k8snode001 ~]# ceph osd pool stats k8s-1 
  2. pool k8s-1 id 2 
  3.   1/1955664 objects degraded (0.000%) 
  4.   1/651888 objects unfound (0.000%) 
  5.   client io 271 KiB/s wr, 0 op/s rd, 52 op/s wr 
  6.  
  7. [root@k8snode001 ~]# ceph osd pool ls detail|grep k8s-1 
  8. 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丢失地块

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

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

  1. [root@k8snode001 ~]# ceph pg 2.2b  query 
  2. {  
  3.     "...... 
  4.     "recovery_state": [ 
  5.         {  
  6.             "name": "Started/Primary/Active",处程 
  7.             "enter_time": "2020-07-21 14:17:05.855923", 
  8.             "might_have_unfound": [], 
  9.             "recovery_progress": {  
  10.                 "backfill_targets": [], 
  11.                 "waiting_on_backfill": [], 
  12.                 "last_backfill_started": "MIN", 
  13.                 "backfill_info": {  
  14.                     "begin": "MIN", 
  15.                     "end": "MIN", 
  16.                     "objects": [] 
  17.                 }, 
  18.                 "peer_backfill_info": [], 
  19.                 "backfills_in_flight": [], 
  20.                 "recovering": [], 
  21.                 "pg_backend": {  
  22.                     "pull_from_peer": [], 
  23.                     "pushing": [] 
  24.                 } 
  25.             }, 
  26.             "scrub": {  
  27.                 "scrubber.epoch_start": "10370", 
  28.                 "scrubber.active": false, 
  29.                 "scrubber.state": "INACTIVE", 
  30.                 "scrubber.start": "MIN", 
  31.                 "scrubber.end": "MIN", 
  32.                 "scrubber.max_end": "MIN", 
  33.                 "scrubber.subset_last_update": "0'0", 
  34.                 "scrubber.deep": false, 
  35.                 "scrubber.waiting_on_whom": [] 
  36.             } 
  37.         }, 
  38.         {  
  39.             "name": "Started", 
  40.             "enter_time": "2020-07-21 14:17:04.814061" 
  41.         } 
  42.     ], 
  43.     "agent_state": { } 

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

5.解决方案

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

 6.验证

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

  1. [root@k8snode001 ~]#  ceph pg  2.2b query 
  2. {  
  3.     "state": "active+clean",处程 
  4.     "snap_trimq": "[]", 
  5.     "snap_trimq_len": 0, 
  6.     "epoch": 11069, 
  7.     "up": [ 
  8.         12, 
  9.         22, 
  10.         4 
  11.     ], 

 再次查看集群状态

  1. [root@k8snode001 ~]# ceph health detail 
  2. HEALTH_OK 

 【编辑推荐】

  1. 为什么有的网站是http,有的理过是https,一s之差,差很大
  2. 5G发展进入关键期,2021年这几大领域应用值得关注
  3. 效率飞起!推荐5款免费好用的Windows工具
  4. 春节回家到底要不要测核酸隔离?教你怎样查清楚
  5. 2021年值得关注的10大网络安全工具

 

责任编辑:姜华 来源: 今日头条 Ceph octopus集群运维

(责任编辑:休闲)

    推荐文章
    热点阅读