1. 问题背景
PG是ceph中承担IO的逻辑单位，PG的状态表示该集群是否可以承接业务；正常情况下PG状态都是active+clean的，当出现网络、硬件等故障时，PG状态就会出现波动，因此理解PG的每一个状态所代表的意义就十分重要。
2. PG状态含义
|
状态 |
描述 |
|
Activating |
PG已经互联，但是还没有active；Peering已经完成，PG正在等待所有PG实例同步并固化Peering的结果(Info、Log等) |
|
Active |
PG可以正常处理来自客户端的读写请求；PG正常的状态应该是Active+Clean的 |
|
Backfilling |
peering完成后，无法通过recover恢复的数据，都通过直接cp方式来恢复 |
|
Backfill-toofull |
backfill操作因为目标OSD容量超过指标而挂起 |
|
backfill_unfound |
Backfill因为没有找到对应对象而停止 |
|
backfill_wait |
PG正在等待backfill被调度执行 |
|
Creating |
PG正在被创建 |
|
Scrubing/Deep-scrubing |
Ceph 正在检查PG数据和checksums的一致性 |
|
Degraded |
PG中的一些对象还没有被复制到规定的份数； |
|
Down |
一个包含必备数据的副本离线，所以PG也离线了 |
|
Incomplete |
Ceph 探测到某一PG可能丢失了写入信息，或者没有健康的副本；EC的话，临时调整一下`min_size`也可能完成恢复 |
|
Inconsistent |
scrub/deep-scrub检测到PG中对象的一份或多份数据不一致 |
|
Peered |
PG已互联，但是不能向客户端提供服务，因为其副本数没达到本存储池的配置值；副本模式修改min_size |
|
Peering |
PG内的OSD达成一致，不涉及数据迁移等操作 |
|
Recovering |
集群数据恢复 |
|
Recovering-wait |
等待recovery资源预留。PG正在等待恢复被调度执行 |
|
recovery_toofull |
恢复操作因为目标OSD容量超过指标而挂起 |
|
recovery_unfound |
恢复因为没有找到对应对象而停止 |
|
Remapped |
PG被临时分配到了和CRUSH所指定的不同的OSD上 |
|
Repair |
Ceph正在检查PG并且修复所有发现的不一致情况 |
|
Unactive |
非活跃态。PG不能处理读写请求 |
|
Unclean |
非干净态。PG不能从上一个失败中恢复 |
|
Stale |
PG状态未知，从PG mapping更新后Monitor一直没有收到更新 |
|
snaptrim |
正在对快照做Trim操作 |
|
Undersized |
该PG的副本数量小于存储池所配置的副本数量 |
3. Incomplete/peered PG问题处理
生产中由于硬盘、内存等硬件的随机故障，存储集群的数据长期来看是在处于动态迁移中；如果出现某些批次或型号的硬盘故障率高，数据迁移来不及，新的硬盘故障在持续，因此时常会出现incomplete、peered状态pg，这也是在释放一个危险信号，集群数据的副本数不足了，需要在新业务写入和存量数据迁移之前做选择，保障数据安全。
- EC pool中出现incomplete pg，此时该状态pg无法承担写入请求，临时解决方案：
查找incomplete pg：ceph pg dump | grep incomplete
查看该pg所在pg：ceph osd pool ls detail
调整pool min_size：ceph osd pool set xx min_size k-1
- 副本pool中出现peered pg，该状态pg无法承接写入请求，临时解决方案：
查找incomplete pg：ceph pg dump | grep incomplete
查看该pg所在pg：ceph osd pool ls detail
调整pool min_size：ceph osd pool set xx min_size 1
