PG异常状态详解及故障总结

这里PG状态指PG外部状态，即能被用户所直接看到的状态。

可以通过 ceph pg stat 命令查看PG当前状态，健康状态为“active + clean”.

下面给出部分常见的PG外部状态。（参考《Ceph 之Rados设计原理与实现》6.3节）

下面给出部分PG异常状态（需要人为修复）介绍。

一般情况下，存储池设置为3副本，也就是1个PG会存储到3个OSD。正常情况，PG状态显示为“active + clean”

如果说你的集群小于三副本，例如只有2个OSD，那么你可能会所有OSD都处于 up 和 in状态，但是PG始终无法达到 “active + clean”，这可能是因为 osd pool size/min_size设置了大于2的值。

可以看出，osd pool min_size是必须满足的OSD副本数，osd pool size则是建议满足的OSD副本数。前者是必须满足的条件，否则该pool无法读写；后者可以不满足，只是集群会报出警告。可以通过设置合理的osd pool size 和osd pool min size来解决上述问题。

CRUSH MAP 错误

PG 达不到 clean 状态的另一个可能的原因就是集群的 CRUSH Map 有错误，导致 PG 不能映射到正确的地方。

最常见的PG故障都是由于某个或者多个OSD进程挂掉导致的。一般重启OSD后恢复健康。

可以通过 ceph -s 或者 ceph osd stat 检查是否有OSD down。

尝试停掉一个或多个OSD（3副本集群，总共4个OSD），观察集群状态。

重启所有停掉的OSD，集群会慢慢恢复健康。

这里罗列一下集群不能读写的PG状态：

stale和peered状态上文已经演示过，通过停止OSD服务达到。

down的一个经典场景：A（主）、B、C

此时存活的B数据陈旧（不含新数据），而且集群中也没有其他OSD可以帮助其完成数据迁移，因此会显示down，参考链接： https://zhuanlan.zhihu.com/p/138778000#:~:text=3.8.3%20PG%E4%B8%BADown%E7%9A%84OSD%E4%B8%A2%E5%A4%B1%E6%88%96%E6%97%A0%E6%B3%95%E6%8B%89%E8%B5%B7

down的解决方法依然是重启失败的OSD。

参考链接： https://ceph.com/geen-categorie/ceph-manually-repair-object/

一般手动修复损坏的PG即可，使用 ceph pg repair {pgid}

PG状态为inconsistent时，说明PG中存在对象不一致的情况。有可能时某个OSD磁盘损坏，或者磁盘上的数据发生静默错误。

下面手动构造一个PG数据损坏的例子，并修复它。

如果 ceph pg repair {pgid} 命令无法修复PG，可以使用ceph-objectstore-tool导入整个PG的方式。

参考链接： https://www.jianshu.com/p/36c2d5682d87#:~:text=%E8%B5%B7%E5%A4%AF%E4%BD%8F%E3%80%82-,3.9%20Incomplete,-Peering%E8%BF%87%E7%A8%8B%E4%B8%AD

构造故障

使用ceph-objectstore-tool修复

上述介绍了重启OSD的方法来解决集群故障，但有时会遇到OSD down却无法重启的状况。

遇到以上问题，有以下三种方案：

下面给出手动删除OSD再重新创建OSD的例子：

重建OSD需要注意的是，如果你的集群中对crush map做了特别定制，那么还需要去检查crush map。

在OSD恢复过程中，可能会影响集群对外提供的io服务。这里给出以下可修改配置。

为了避免pg开始迁移后造成较大的压力导致osd挂掉，先在配置文件global中写入如下配置

磁盘恢复速度配置，其实默认的速度已经比较写了，如果想要加快迁移速度，可以尝试调制下列参数

附上配置 *** 控命令

一般来说，集群三副本的情况下不太可能出现PG丢失的情况，如果一旦出现了，那也就意味着这丢失的数据无法找回。

注意：不要使用单副本的集群。

出现“1 pools have many more objects per pg than average”警告时，说明集群中某个pool的PG数量配置过少，其每个PG承载的对象高于集群平均PG承载对象10倍以上，最简单的解决方法就是增加pool的pg数即可。

PG默认每个page的大小为8K，PG数据页写入是以page为单位，但是在断电等情况下， *** 作系统往往不能保证单个page原子地写入磁盘，这样就极有可能导致部分数据块只写到4K( *** 作系统是一般以4K为单位)，这些“部分写”的页面包含新旧数据的混合。在崩溃后的恢复期间，xlog 里面存储的记录变化信息不够完整，无法完全恢复该页。PG为了解决这类问题，full_page_write机制孕育而生。

PostgreSQL 在 checkpoint 之后在对数据页面的第一次写的时候会将整个数据页面写到 xlog 里面。当出现主机断电或者OS崩溃时，redo *** 作时通过checksum发现“部分写”的数据页，并将xlog中保存的这个完整数据页覆盖当前损坏的数据页，然后再继续redo就可以恢复整个数据库了。

除了能够解决断电等带来坏数据页问题外，full_page_write 还应用在在线备份功能上。PG进行全量备份数据库一般通过pg_basebackup工具实现，pg_basebackup类似于copy *** 作，在此期间，也会出现部分数据页写到一半时文件被copy走了，正是因为full_page_write存在，备份出来的数据库才可以成功恢复启动。所以即便full_page_write=off，在备份时也会被强制自动打开，保证备份成功。

实现原理

full_page_write主要在XLogInsert(插入一条xlog记录)时发挥作用，通过full_page_writer开关状态以及是否是checkpoint后对数据页面的第一次修改(lsn<RedoRecPtr)判断是否需要备份数据页。如果需要备份，那么则把数据页存放在这条记录的末尾，最终写入到xlog中。

---