PG 的常见在状态如下：
Peering
正在同步状态，同一个 PG 中的 OSD 需要将准备数据同步一致，而 Peering(对等)就是 OSD同步过程中的状态。
Activating
Peering 已经完成，PG 正在等待所有 PG 实例同步 Peering 的结果(Info、Log 等)
Clean
干净态,PG 当前不存在待修复的对象，并且大小等于存储池的副本数，即 PG 的活动集(Acting Set)和上行集(Up Set)为同一组 OSD 且内容一致。
活动集(Acting Set)：由 PG 当前主的 OSD 和其余处于活动状态的备用 OSD 组成，当前 PG内的 OSD 负责处理用户的读写请求。
上行集(Up Set):在某一个 OSD 故障时，需要将故障的 OSD 更换为可用的 OSD，并且PG内部的主 OSD 同步数据到新的 OSD 上，例如 PG 内有 OSD1、OSD2、OSD3，当 OSD3故障后需要用 OSD4 替换 OSD3，那么 OSD1、OSD2、OSD3 就是上行集，替换后 OSD1、OSD2、OSD4 就是活动集，OSD 替换完成后活动集最终要替换上行集。
Active
就绪状态或活跃状态，Active 表示主 OSD 和备 OSD 处于正常工作状态，此时的 PG 可以正常处理来自客户端的读写请求，正常的 PG 默认就是 Active+Clean 状态。
cephadmin@ceph-deploy:/home/ceph/ceph-cluster$ ceph pg stat
129 pgs: 129 active+clean; 319 KiB data, 1.1 GiB used, 2.0 TiB / 2.0 TiB avail
Degraded
降级状态降级状态出现于 OSD 被标记为 down 以后，那么其他映射到此 OSD 的 PG 都会转换到降级状态。
如果此 OSD 还能重新启动完成并完成 Peering 操作后，那么使用此 OSD 的 PG 将重新恢复为 clean 状态。
如果此 OSD 被标记为 down 的时间超过 5 分钟还没有修复，那么此 OSD 将会被 ceph 踢出集群，然后 ceph 会对被降级的 PG 启动恢复操作，直到所有由于此 OSD 而被降级的 PG重新恢复为 clean 状态。恢复数据会从 PG 内的主 OSD 恢复，如果是主 OSD 故障，那么会在剩下的两个备用 OSD重新选择一个作为主 OSD。
Stale过期状态
正常状态下，每个主 OSD 都要周期性的向 RADOS 集群中的监视器(Mon)报告其作为主 OSD所持有的所有 PG 的最新统计数据，因任何原因导致某个 OSD 无法正常向监视器发送汇报信息的、或者由其他 OSD 报告某个 OSD 已经 down 的时候，则所有以此 OSD 为主 PG 则会立即被标记为 stale 状态，即他们的主 OSD 已经不是最新的数据了，如果是备份的 OSD发送 down 的时候，则 ceph 会执行修复而不会触发 PG 状态转换为 stale 状态。
undersized
PG 当前副本数小于其存储池定义的值（默认为3副本）的时候，PG 会转换为 undersized 状态，比如两个备份 OSD 都 down 了（只有1个osd在线），那么此时 PG 中就只有一个主 OSD 了，不符合 ceph 最少要求一个主 OSD 加一个备 OSD 的要求（2个osd在线则可以继续提供对外读写），那么就会导致使用此 OSD 的 PG 转换为 undersized 状态直到添加备份 OSD 添加完成，或者修复完成。
Scrubbing
scrub 是 ceph 对数据的清洗状态，用来保证数据完整性的机制，Ceph 的 OSD 定期启动 scrub 线程来扫描部分对象，通过与其他副本比对来发现是否一致，如果存在不一致，抛出异常提示用户手动解决，scrub 以 PG 为单位，对于每一个 pg，ceph 分析该 pg 下所有的 object, 产生一个类似于元数据信息摘要的数据结构，如对象大小，属性等，叫 scrubmap,比较主与副 scrubmap，来保证是不是有 object 丢失或者不匹配，扫描分为轻量级扫描和深度扫描，轻量级扫描也叫做 light scrubs 或者 shallow scrubs 或者 simply scrubs 即轻量级扫描.
Light scrub(daily)比较 object size 和属性，deep scrub (weekly)读取数据部分并通过checksum(CRC32 算法)对比和数据的一致性, 深度扫描过程中的PG会 处 于scrubbing+deep 状态。
Recovering
正在恢复态，集群正在执行迁移或同步对象和他们的副本，这可能是由于添加了一个新的OSD 到集群中或者某个 OSD 宕掉后，PG 可能会被 CRUSH 算法重新分配不同的 OSD，而由于 OSD 更换导致 PG 发生内部数据同步的过程中的 PG 会被标记为 Recovering。
Backfilling
正在后台填充态,backfill 是 recovery 的一种特殊场景，指 peering 完成后，如果基于当前权威日志无法对 Up Set（上行集）当中的某些 PG 实例实施增量同步(例如承载这些 PG 实例的 OSD 离线太久，或者是新的 OSD 加入集群导致的 PG 实例整体迁移) 则通过完全拷贝当前 Primary 所有对象的方式进行全量同步，此过程中的 PG 会处于 backfilling。
Backfill-toofull
某个需要被 Backfill 的 PG 实例，其所在的 OSD 可用空间不足，Backfill 流程当前被挂起时PG 给的状态。
标签：Peering,状态,ceph,同步,常见,Ceph,PG,OSD,pg From： https://www.cnblogs.com/punchlinux/p/17067296.html