postgresql Degraded

Degraded
降级：由上文可以得知，每个PG有三个副本，分别保存在不同的OSD中，在非故障情况下，这个PG是a+c状态，那么，如果保存0.44这个PG的osd.4挂掉了，这个PG是什么状态呢，操作如下：
 
[root@ceph-2 ~]# service ceph stop osd.4

=== osd.4 ===

Stopping Ceph osd.4 on ceph-2...kill 6475...kill 6475...done

[root@ceph-2 ~]# ceph pg dump_stuck |egrep ^0.44

0.44 active+undersized+degraded [0,7] 0 [0,7] 0

这里我们前往ceph-2节点，手动停止了osd.4，然后查看此时pg 0.44的状态，可见，它此刻的状态是active+undersized+degraded,当一个PG所在的OSD挂掉之后，这个PG就会进入undersized+degraded状态，而后面的[0,7]的意义就是还有两个0.44的副本存活在osd.0和osd.7上。那么现在可以读取刚刚写入的那个文件吗？是可以正常读取的！
 

[root@ceph-1 0.44_head]# rados -p rbd get char char.txt

[root@ceph-1 0.44_head]# cat char.txt

abcdefg

降级就是在发生了一些故障比如OSD挂掉之后，ceph将这个OSD上的所有PG标记为degraded，但是此时的集群还是可以正常读写数据的，降级的PG只是相当于小感冒而已，并不是严重的问题，而另一个词undersized,我的理解就是当前存活的PG 0.44数为2，小于副本数3，将其做此标记，也不是严重的问题。

Peered
那么，什么才是PG的大病呢，peered算是一个，刚刚我们关闭了osd.4，集群里还活着两个PG 0.44，现在我们关闭osd.7，查看下0.44的状态：

 
[root@ceph-3 0.44_head]# service ceph stop osd.7

=== osd.7 ===

Stopping Ceph osd.7 on ceph-3...kill 5986...kill 5986...done

[root@ceph-2 ~]# ceph pg dump_stuck |egrep ^0.44

0.44 undersized+degraded+peered [0] 0 [0] 0

可见，现在只剩下独苗苗活在osd.0上了，并且0.44还多了一个状态：peered，英文的意思是仔细看，这里我们可以理解成协商、搜索，这时候读取char.txt文件，会发现指令会卡在那个地方一直不动，如此来解释min_size的作用，在ceph中，它的全名叫做osd_pool_default_min_size，这里大家就会问了，不是还活着一个呢吗，为什么就不能读取内容了，因为我们设置的min_size=2，在ceph中的意义就是，如果存活数少于2了，比如这里的1 ，那么ceph就不会响应外部的IO请求。

在这里如果执行指令,将min_size设置为1:

 

[root@ceph-2 ~]# ceph osd pool set rbd min_size 1

[root@ceph-2 ~]# ceph pg dump_stuck |egrep ^0.44

0.44 active+undersized+degraded [0] 0 [0] 0

可以看到，0.44没有了peered状态，并且文件可以正常读写了，因为min_size=1时，只要集群里面有一份副本活着，那就可以响应外部的IO请求。

peered，我们这里可以将它理解成它在等待其他兄弟姐妹上线，这里也就是osd.4和osd.7的任意一个上线就可以去除这个状态了，处于peered状态的PG是不能响应外部的请求的，外部就会觉得卡卡的。

Remapped
ceph强大的自我恢复能力，是我们选择它的一个重要原因，在上面的试验中，我们关闭了两个OSD，但是至少还有一个PG 0.44存活在osd.0上，如果那两个盘真的坏了，ceph还是可以将这份仅存的数据恢复到别的OSD上的。

在OSD挂掉5min(default 300s)之后，这个OSD会被标记为out状态，可以理解为ceph认为这个OSD已经不属于集群了，然后就会把PG 0.44 map到别的OSD上去，这个map也是按照一定的规则的，重映射之后呢，就会在另外两个OSD上找到0.44这个PG，而这只是创建了这个目录而已，丢失的数据是要从仅存的OSD上回填到新的OSD上的，处于回填状态的PG就会被标记为backfilling。

所以当一个PG处于remapped+backfilling状态时，可以认为其处于自我克隆复制的自愈过程。

Recover
这里我们先来做一个实验，首先开启所有OSD使得集群处于健康状态，然后前往osd.4的PG 0.44下面删除char__head_98165844__0这个文件，再通知ceph扫描(scrub)这个PG：

 
[root@ceph-2 0.44_head]# pwd && rm -f char__head_98165844__0

/var/lib/ceph/osd/ceph-4/current/0.44_head

[root@ceph-2 0.44_head]# ceph pg scrub 0.44

[root@ceph-2 0.44_head]# ceph pg dump |egrep ^0.44

active+clean+inconsistent [0,7,4] 0 [0,7,4] 0

可见，0.44多了个inconsistent状态，顾名思义，ceph发现了这个PG的不一致状态，这样就可以理解这个状态的意义了。

想要修复丢失的文件呢，只需要执行ceph pg repair 0.44，ceph就会从别的副本中将丢失的文件拷贝过来，这也是ceph自愈的一个情形。

现在再假设一个情形，在osd.4挂掉的过程中呢，我们对char文件进行了写操作，因为集群内还存在着两个副本，是可以正常写入的，但是osd.4内的数据并没有得到更新，过了一会，osd.4上线了，ceph就发现，osd.4的char文件是陈旧的，就通过别的OSD向osd.4进行数据的恢复，使其数据为最新的，而这个恢复的过程中，PG就会被标记为recover。

总结
至此，我们对PG在磁盘的具体意义进行了分析，相信大家也对PG有了更深入的理解，同时，对常见的PG状态进行了剖析，今后看到了长长的病例单也不会有所畏惧了。
最后，本文对PG状态的解释都基于作者对ceph浅显的理解，如果有错误的地






原文链接：https://blog.csdn.net/bandaoyu/article/details/120348914