含義：pg正在建立
引起原因：建立pool的時候，根據指定的pg數量進行建立pg時出現的狀態，正常狀態
後果：無
解決方案：無需解決，正常狀態之一peering
含義：pg之間進行互聯，就其中的物件和元資料狀態達成一致
引起原因：當pg被creating之後，會進行互聯，儲存歸置組副本的 osd 之間就其中的物件和元資料狀態達成一致。
後果：無
解決方案：無需解決，正常狀態之一
含義：pg在完成peering過程後，會對之前的結果進行固化，等待所有pg同步，嘗試進入active狀態
引起原因：pg進入active前的準備狀態
後果：如果長期卡在該狀態，會影響該pg無法讀寫，進而影響整個pool可用性
解決方案：停掉pg所在所有osd
用ceph-object-tool進行pg資料備份
用ceph-object-tool在主pg上刪除空的pg（不要手動刪除）
再次使用ceph-object-tool匯入資料
手動給該pg目錄賦ceph許可權
最後重啟osd即可
含義：pg是活躍態，可以進行讀寫操作
引起原因：正常狀態
後果：無
解決方案：無需解決，正常狀態之一
含義：回填狀態
引起原因：這種情況一般是由於osd的離線（超過5分鐘沒有心跳回應），ceph找尋新的osd來替換所進行的全量資料拷貝。
後果：出現這個狀態一般都是確定有osd掛掉或者離線了
解決方案：多數情況下ceph會自動完成資料回填，如果無法完成回填，就會進入backfill-toofull狀態
含義：backfilling掛起狀態
引起原因：通常是因為osd容量不足以回填丟失的osd引起
後果：造成pool無法寫入，讀寫卡死。
解決方案：需要檢查osd容量，是否有嚴重不平衡現象，將超量osd資料手動疏散（reweight），如果是集群nearful現象，應該盡快物理擴容
緊急擴容方式（治標不治本，最好的方法還是擴充套件osd數量和容量）
暫停osd讀寫：
ceph osd pause
通知mon和osd修改full閾值
ceph tell mon.* injectargs "--mon-osd-full-ratio 0.96"
ceph tell osd.* injectargs "--mon-osd-full-ratio 0.96"
通知pg修改full閾值：
ceph pg set_full_ratio 0.96
解除osd禁止讀寫：
ceph osd unpause
含義：pg正在等待開始回填操作。
引起原因：osd離線造成（未親自捕獲該狀態，可能是太快了沒看到）
後果：接下來理論來講pg會進入backfilling狀態進行資料回填
解決方案：正常的回填必經狀態，無需特殊關注
含義：peering過程中發現無法就資料狀態達成一致
引起原因：pg在選擇權威日誌的時候，權威日誌沒法完成，或者權威日誌完成後和本地日誌對比邏輯不正常
後果：通常會導致pg無法建立，卡在creating+incomplete狀態，進而導致pool無法使用
解決方案：首先確認osd_allow_recovery_below_min_size為true，還有副本數量是否合理，crushmap配置的選取osd數量是否與pool一致，如果都正常，嘗試執行以下恢復流程
停掉所有incomplete的pg對應的每乙個osd
使用ceph-object-tool對osd進行mark complete
然後重啟osd
含義：其實就是副本資料不一致的意思
引起原因：某個副本資料未知原因丟失
後果：副本資料不一致導致安全性下降
解決方案：使用ceph pg repair工具進行資料修復，一般情況下都可以恢復正常，如果無法恢復
把三副本的osd的osd_max_scrubs都先調大,再次使用使用ceph pg repair工具進行資料修復，最後再將osd_max_scrubs調回1
含義：搜尋中，指的是pg找不到足夠的副本來進行讀寫操作（連min_size都無法滿足的情況下）
引起原因：多個osd掛掉，造成當前活躍osd副本數後果：pg無法使用，甚至pool無法進行常規io
1 嘗試啟動副本osd，重新加入集群，peered會自動消失
2 主動out掉失聯的osd，ceph會自動進入修復狀態
含義：恢復中
引起原因：當某 osd 掛了（ down ）時，其內的歸置組會落後於別的歸置組副本；此 osd 重生（ up ）時，歸置組內容必須更新到當前狀態；
後果：恢復並非總是這些小事，因為一次硬體失敗可能牽連多個 osd 。比如乙個機櫃或房間的網路交換機失敗了，這會導致多個主機上的 osd 落後於集群的當前狀態，故障恢復後每乙個 osd 都必須恢復。
解決方案：集群出現這個狀態，說明pg正在自動恢復，等它恢復完成就好了。
含義：等待 recovery 資源預留
引起原因：pg正在等待恢復。
後果：理論來講pg會進入recovering狀態進行資料恢復
解決方案：正常的恢復狀態。
含義：重新對映態
引起原因：當acting集合裡面的pg組合發生變化時，資料從舊的集合遷移到新的集合中。這段時間可能比較久，新集合的主osd在遷移完之前不能響應請求。所以新主osd會要求舊主osd繼續服務指導pg遷移完成。一旦資料遷移完成，新主osd就會生效接受請求。
後果：如果無法重新對映，資料就無法進行遷移，會造成資料的丟失。
解決方案：在 osd 掛掉或者在擴容的時候pg 上的osd會按照crush演算法重新分配pg 所屬的osd編號。並且會把 pg remap到別的osd上去。
·· 客戶端io可以正常讀寫。
含義：清理中
引起原因：pg正在做不一致性校驗。
後果：會造成io效能下降
解決方案：可以根據實際環境需求，關閉該功能或者降低自檢頻率。
含義：非活躍態,pg 不能處理讀寫請求
引起原因：pg 很長時間沒有顯示為 acitve 狀態, (不可執行讀寫請求), pg 不可以執行讀寫,
後果：pg 不可以執行讀寫
解決方案：等待 osd 更新資料到最新的備份狀態
引起原因：歸置組裡有些物件的副本數未達到期望次數，它們應該在恢復中；
後果：資料安全性下降
解決方案：通常都要執行恢復操作
含義：為重新整理態，pg沒有被任何osd更新
引起原因：很可能是osd掛掉引起的，一般情況下跟隨peering狀態一起出現
模擬：手動停掉乙個osd，systemctl stop ceph-osd@0，檢視ceph -s 會發現在短時間內（peering之前），pg會進入stale+clean+active的特殊狀態
後果：警告標誌，往往代表著osd出現異常，或者某節點斷網。
解決方案：一般情況下只需要等待peering完成即可。
含義：副本數過小
引起原因：該pg的副本數量小於儲存池所配置的副本數量。通常是由於乙個osd服務down了，出現此狀態。
後果：降低資料可用性
解決方案：調整pg所在池的副本數 osd pool default min size =1 ，不建議調整。等osd服務起來就好了
含義：失效
引起原因：歸置組的權威副本osd宕機，必須等待其開機，或者被標記為lost才能繼續
後果：這個時候該 pg 不能提供客戶端 io 讀寫， io 會掛起夯住
解決方案：將osd服務起來。
ceph pg 常見狀態
pg placement group 是資料儲存的重要單位 在使用 ceph 的時候,pg 會經常發生狀態的變化,參考下面例子 當建立池的時候,將會建立相應的 pg,那麼可以看到 pg creating 狀態 當部分 pg 建立成功後,將會發現 pg 會進入 peering 狀態 當所有 pg pe...
ceph pg 常見狀態
參考 ceph pg 常見狀態 說明 pg placement group 是資料儲存的重要單位 在使用 ceph 的時候,pg 會經常發生狀態的變化,參考下面例子 1.當建立池的時候,將會建立相應的 pg,那麼可以看到 pg creating 狀態 2.當部分 pg 建立成功後,將會發現 pg 會...
svn st 狀態詳解
svn st help status stat,st 顯示工作副本中目錄與檔案的狀態。用法 status path.未指定引數時，只顯示本地修改的條目 沒有網路訪問 使用 q 時，只顯示本地修改條目的摘要資訊。使用 u 時，增加工作版本和伺服器上版本過期資訊。使用 v 時，顯示每個條目的完整版本資訊...