1. 問題背景
PG是ceph中承擔IO的邏輯單位，PG的狀態表示該集群是否可以承接業務；正常情況下PG狀態都是active+clean的，當出現網絡、硬件等故障時，PG狀態就會出現波動，因此理解PG的每一個狀態所代表的意義就十分重要。
2. PG狀態含義
|
狀態 |
描述 |
|
Activating |
PG已經互聯，但是還沒有active；Peering已經完成，PG正在等待所有PG實例同步并固化Peering的結果(Info、Log等) |
|
Active |
PG可以正常處理來自客戶端的讀寫請求；PG正常的狀態應該是Active+Clean的 |
|
Backfilling |
peering完成后，無法通過recover恢復的數據，都通過直接cp方式來恢復 |
|
Backfill-toofull |
backfill操作因為目標OSD容量超過指標而掛起 |
|
backfill_unfound |
Backfill因為沒有找到對應對象而停止 |
|
backfill_wait |
PG正在等待backfill被調度執行 |
|
Creating |
PG正在被創建 |
|
Scrubing/Deep-scrubing |
Ceph 正在檢查PG數據和checksums的一致性 |
|
Degraded |
PG中的一些對象還沒有被復制到規定的份數； |
|
Down |
一個包含必備數據的副本離線，所以PG也離線了 |
|
Incomplete |
Ceph 探測到某一PG可能丟失了寫入信息，或者沒有健康的副本；EC的話，臨時調整一下`min_size`也可能完成恢復 |
|
Inconsistent |
scrub/deep-scrub檢測到PG中對象的一份或多份數據不一致 |
|
Peered |
PG已互聯，但是不能向客戶端提供服務，因為其副本數沒達到本存儲池的配置值；副本模式修改min_size |
|
Peering |
PG內的OSD達成一致，不涉及數據遷移等操作 |
|
Recovering |
集群數據恢復 |
|
Recovering-wait |
等待recovery資源預留。PG正在等待恢復被調度執行 |
|
recovery_toofull |
恢復操作因為目標OSD容量超過指標而掛起 |
|
recovery_unfound |
恢復因為沒有找到對應對象而停止 |
|
Remapped |
PG被臨時分配到了和CRUSH所指定的不同的OSD上 |
|
Repair |
Ceph正在檢查PG并且修復所有發現的不一致情況 |
|
Unactive |
非活躍態。PG不能處理讀寫請求 |
|
Unclean |
非干凈態。PG不能從上一個失敗中恢復 |
|
Stale |
PG狀態未知，從PG mapping更新后Monitor一直沒有收到更新 |
|
snaptrim |
正在對快照做Trim操作 |
|
Undersized |
該PG的副本數量小于存儲池所配置的副本數量 |
3. Incomplete/peered PG問題處理
生產中由于硬盤、內存等硬件的隨機故障，存儲集群的數據長期來看是在處于動態遷移中；如果出現某些批次或型號的硬盤故障率高，數據遷移來不及，新的硬盤故障在持續，因此時常會出現incomplete、peered狀態pg，這也是在釋放一個危險信號，集群數據的副本數不足了，需要在新業務寫入和存量數據遷移之前做選擇，保障數據安全。
- EC pool中出現incomplete pg，此時該狀態pg無法承擔寫入請求，臨時解決方案：
查找incomplete pg：ceph pg dump | grep incomplete
查看該pg所在pg：ceph osd pool ls detail
調整pool min_size：ceph osd pool set xx min_size k-1
- 副本pool中出現peered pg，該狀態pg無法承接寫入請求，臨時解決方案：
查找incomplete pg：ceph pg dump | grep incomplete
查看該pg所在pg：ceph osd pool ls detail
調整pool min_size：ceph osd pool set xx min_size 1
