数据来源：https://www.cnblogs.com/zyxnhr/p/10616497.html

PG状态

• Creating：PG正在被创建。通常当存储池被创建或者PG的数目被修改时，会出现这种状态

• Active：PG处于活跃状态。可被正常读写

• Clean：PG中的所有对象都被复制了规定的副本数

• Down：PG离线

• Replay：当某个OSD异常后，PG正在等待客户端重新发起操作

• Splitting：PG正在初分割，通常在一个存储池的PG数增加后出现，现有的PG会被分割，部分对象被移动到新的PG

• Scrubbing：PG正在做不一致校验

• Degraded：PG中部分对象的副本数未达到规定数目

• Inconsistent：PG的副本出现了不一致。如果出现副本不一致，可使用ceph pg repair来修复不一致情况

• Peering：Perring是由主OSD发起的使用存放PG副本的所有OSD就PG的所有对象和元数据的状态达成一致的过程。Peering完成后，主OSD才会接受客户端写请求

• Repair：PG正在被检查，并尝试修改被发现的不一致情况

• Recovering：PG正在迁移或同步对象及副本。通常是一个OSD down掉之后的重平衡过程

• Backfill：一个新OSD加入集群后，CRUSH会把集群现有的一部分PG分配给它，被称之为数据回填

• Backfill-wait：PG正在等待开始数据回填操作

• Incomplete：PG日志中缺失了一关键时间段的数据。当包含PG所需信息的某OSD不可用时，会出现这种情况

• Stale：PG处理未知状态。monitors在PG map改变后还没收到过PG的更新。集群刚启动时，在Peering结束前会出现该状态

• Remapped：当PG的acting set变化后，数据将会从旧acting set迁移到新acting set。新主OSD需要一段时间后才能提供服务。因此这会让老的OSD继续提供服务，直到PG迁移完成。在这段时间，PG状态就会出现Remapped

PG异常状态

• inactive：pg有peering问题

• unclean：pg在故障恢复时遇到问题

• stale：pg没有任何OSD报告，可能其所有的OSD都是down和out

• undersized：pg没有充足的osd来存储它应具有的副本数

默认情况下，Ceph会自动执行恢复，但如果未成自动恢复，则集群状态会一直处于HEALTH_WARN或者HEALTH_ERR
如果特定PG的所有osd都是down和out状态，则PG会被标记为stale。要解决这一情况，其中一个OSD必须要重生，且具有可用的PG副本，否则PG不可用
Ceph可以声明osd或PG已丢失，这也就意味着数据丢失。
需要说明的是，osd的运行离不开journal，如果journal丢失，则osd停止

指尖风暴终身VIP

收藏 海报分享