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

发布网友发布时间：2022-12-21 09:18

共3个回答

热心网友时间：2023-10-18 23:31

PG（PostgreSQL）异常状态是指在操作PostgreSQL数据库时可能会出现的异常状态，例如：1. 数据库连接异常：无法连接到数据库或连接被中断；2. 查询异常：执行SQL查询语句时出错，例如语法错误、数据类型不匹配等；3. 数据库操作异常：执行数据库操作（例如插入、更新、删除等）时出现异常；4. 数据库锁定异常：多个并发事务访问同一数据时可能出现锁定异常；5. 数据库崩溃：数据库程序崩溃或发生硬件故障等原因导致数据库无法正常工作。针对以上异常状态，可以采取以下措施：1. 数据库连接异常：检查网络连接、认证信息、数据库运行状态等；2. 查询异常：检查SQL语法、数据类型、查询条件等；3. 数据库操作异常：根据异常信息进行排查、修复；4. 数据库锁定异常：调整事务隔离级别、优化SQL语句等；5. 数据库崩溃：重启数据库程序、备份恢复等。总之，要保证PostgreSQL数据库的稳定性和可靠性，需要对各种异常状态进行及时的排查和修复。

热心网友时间：2023-10-18 23:31

这里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.hu.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数即可。

热心网友时间：2023-10-18 23:32

PG( (参考 ,文档)Primary Global)异常状态是指数据库中的主节点(Primary Node)无法正常工作。出现PG异常状态可能是由于主节点故障、网络连接问题、负载过重等原因导致的。当主节点出现异常时,数据库会自动切换到备用节点(Standby Node),以确保系统的高可用性和数据的连续性。造成PG异常状态的常见故障有:1. 主节点故障:主节点宕机或出现故障,导致无法提供正常的数据库服务。这可能是由于硬件故障、操作系统故障、数据库软件故障等原因引起的。2. 网络连接问题:主节点与备用节点之间的网络连接出现问题,导致数据无法正常同步和传输。可能是由于网络故障、防火墙配置不正确、网络带宽不足等原因引起的。3. 负载过重:主节点所承载的负载过大,超出了其能力范围,导致数据库性能下降甚至宕机。这可能是由于并发用户数过多、数据库请求压力过大、资源分配不合理等原因引起的。对于PG异常状态,需要采取以下几个步骤进行故障处理和修复:1. 检查主节点状态:首先需要确认主节点是否真的宕机或出现故障。可以通过登陆到主节点进行检查,查看数据库服务是否正常运行。2. 切换到备用节点:如果主节点确实故障,需要手动切换到备用节点。可以通过修改数据库配置文件或执行相应的命令来实现。切换后,备用节点将成为新的主节点,负责提供数据库服务。3. 恢复主节点:修复主节点的故障,使其能够重新加入数据库集群。这可能需要修复硬件故障、处理操作系统故障、重新安装数据库软件等。4. 优化数据库配置和资源分配:对于负载过重的情况,需要进行数据库配置和资源分配的优化。可以增加硬件资源、优化数据库参数设置、控制并发用户数等。总结起来,PG异常状态是数据库中的主节点出现故障导致的,可能是由于主节点故障、网络连接问题、负载过重等原因引起的。要解决PG异常状态,需要检查主节点状态、切换到备用节点、修复主节点故障、优化数据库配置和资源分配等步骤。这样可以确保数据库的高可用性和数据的连续性。