Creating
含义：PG正在创建
引起原因：创建pool的时候，根据指定的pg数量进行创建pg时出现的状态，正常状态
后果：无
解决方案：无需解决，正常状态之一Peering
含义：PG之间进行互联，就其中的对象和元数据状态达成一致
引起原因：当pg被creating之后，会进行互联，存储归置组副本的 OSD 之间就其中的对象和元数据状态达成一致。
后果：无
解决方案：无需解决，正常状态之一
Activating
含义：pg在完成peering过程后，会对之前的结果进行固化，等待所有pg同步，尝试进入active状态
引起原因：pg进入active前的准备状态
后果：如果长期卡在该状态，会影响该PG无法读写，进而影响整个pool可用性
解决方案：停掉PG所在所有OSD
用ceph-object-tool进行pg数据备份
用ceph-object-tool在主PG上删除空的pg（不要手动删除）
再次使用ceph-object-tool导入数据
手动给该pg目录赋ceph权限
最后重启osd即可
Active
含义：pg是活跃态，可以进行读写操作
引起原因：正常状态
后果：无
解决方案：无需解决，正常状态之一
Backfilling
含义：回填状态
引起原因：这种情况一般是由于osd的离线（超过5分钟没有心跳回应），ceph找寻新的osd来替换所进行的全量数据拷贝。
后果：出现这个状态一般都是确定有osd挂掉或者离线了
解决方案：多数情况下ceph会自动完成数据回填，如果无法完成回填，就会进入backfill-toofull状态
Backfill-toofull
含义：backfilling挂起状态
引起原因：通常是因为osd容量不足以回填丢失的osd引起
后果：造成pool无法写入，读写卡死。
解决方案：需要检查osd容量，是否有严重不平衡现象，将超量osd数据手动疏散（reweight），如果是集群nearful现象，应该尽快物理扩容
紧急扩容方式（治标不治本，最好的方法还是扩展osd数量和容量）
暂停osd读写：
ceph osd pause
通知mon和osd修改full阈值
ceph tell mon.* injectargs "--mon-osd-full-ratio 0.96"
ceph tell osd.* injectargs "--mon-osd-full-ratio 0.96"
通知PG修改full阈值：
ceph pg set_full_ratio 0.96
解除osd禁止读写：
ceph osd unpause
Backfill-wait
含义：PG正在等待开始回填操作。
引起原因：OSD离线造成（未亲自捕获该状态，可能是太快了没看到）
后果：接下来理论来讲pg会进入backfilling状态进行数据回填
解决方案：正常的回填必经状态，无需特殊关注
Incomplete
含义：peering过程中发现无法就数据状态达成一致
引起原因：pg在选择权威日志的时候，权威日志没法完成，或者权威日志完成后和本地日志对比逻辑不正常
后果：通常会导致pg无法创建，卡在creating+incomplete状态，进而导致pool无法使用
解决方案：首先确认osd_allow_recovery_below_min_size为true，还有副本数量是否合理，crushmap配置的选取osd数量是否与pool一致，如果都正常，尝试执行以下恢复流程
停掉所有incomplete的PG对应的每一个osd
使用ceph-object-tool对osd进行mark complete
然后重启osd
Inconsistent
含义：其实就是副本数据不一致的意思
引起原因：某个副本数据未知原因丢失
后果：副本数据不一致导致安全性下降
解决方案：使用ceph pg repair工具进行数据修复，一般情况下都可以恢复正常，如果无法恢复
把三副本的osd的osd_max_scrubs都先调大,再次使用使用ceph pg repair工具进行数据修复，最后再将osd_max_scrubs调回1
Peered
含义：搜索中，指的是PG找不到足够的副本来进行读写操作（连min_size都无法满足的情况下）
引起原因：多个osd挂掉，造成当前活跃osd副本数<min_size，读写功能锁死
后果：pg无法使用，甚至pool无法进行常规io
解决方案：集群健康状态下，osd挂掉超过5分钟会自动remapped修复该状态，想要快速修复该状态方法有二：
1 尝试启动副本osd，重新加入集群，peered会自动消失
2 主动out掉失联的osd，ceph会自动进入修复状态
Recovering
含义：恢复中
引起原因：当某 OSD 挂了（ down ）时，其内的归置组会落后于别的归置组副本；此 OSD 重生（ up ）时，归置组内容必须更新到当前状态；
后果：恢复并非总是这些小事，因为一次硬件失败可能牵连多个 OSD 。比如一个机柜或房间的网络交换机失败了，这会导致多个主机上的 OSD 落后于集群的当前状态，故障恢复后每一个 OSD 都必须恢复。
解决方案：集群出现这个状态，说明PG正在自动恢复，等它恢复完成就好了。
Recovering-wait
含义：等待 Recovery 资源预留
引起原因：PG正在等待恢复。
后果：理论来讲pg会进入recovering状态进行数据恢复
解决方案：正常的恢复状态。
Remapped
含义：重新映射态
引起原因：当Acting集合里面的PG组合发生变化时，数据从旧的集合迁移到新的集合中。这段时间可能比较久，新集合的主OSD在迁移完之前不能响应请求。所以新主OSD会要求旧主OSD继续服务指导PG迁移完成。一旦数据迁移完成，新主OSD就会生效接受请求。
后果：如果无法重新映射，数据就无法进行迁移，会造成数据的丢失。
解决方案：在 OSD 挂掉或者在扩容的时候PG 上的OSD会按照Crush算法重新分配PG 所属的osd编号。并且会把 PG Remap到别的OSD上去。
· Remapped状态时，PG当前Acting Set与Up Set不一致。
·· 客户端IO可以正常读写。
Scrubbing
含义：清理中
引起原因：pg正在做不一致性校验。
后果：会造成IO性能下降
解决方案：可以根据实际环境需求，关闭该功能或者降低自检频率。
Unactive
含义：非活跃态,PG 不能处理读写请求
引起原因：PG 很长时间没有显示为 acitve 状态, (不可执行读写请求), PG 不可以执行读写,
后果：PG 不可以执行读写
解决方案：等待 OSD 更新数据到最新的备份状态
Unclean
含义：非干净态,PG 不能从上一个失败中恢复
引起原因：归置组里有些对象的副本数未达到期望次数，它们应该在恢复中；
后果：数据安全性下降
解决方案：通常都要执行恢复操作
Stale
含义：为刷新态，pg没有被任何osd更新
引起原因：很可能是osd挂掉引起的，一般情况下跟随peering状态一起出现
模拟：手动停掉一个osd，systemctl stop ceph-osd@0，查看ceph -s 会发现在短时间内（peering之前），pg会进入stale+clean+active的特殊状态
后果：警告标志，往往代表着osd出现异常，或者某节点断网。
解决方案：一般情况下只需要等待peering完成即可。
Undersized
含义：副本数过小
引起原因：该PG的副本数量小于存储池所配置的副本数量。通常是由于一个osd服务down了，出现此状态。
后果：降低数据可用性
解决方案：调整PG所在池的副本数 osd pool default min size =1 ，不建议调整。等osd服务起来就好了
down
含义：失效
引起原因：归置组的权威副本OSD宕机，必须等待其开机，或者被标记为lost才能继续
后果：这个时候该 PG 不能提供客户端 IO 读写， IO 会挂起夯住
解决方案：将OSD服务起来。
