Ceph pg状态
指尖风暴 数据来源：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停止
