共計 1183 個字符，預計需要花費 3 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關錯誤狀況下怎么保證 ceph IO 的一致性，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

最近研究了在出現錯誤的狀況下，ceph IO 的一致性如何保證。代碼基于 hammer0.94.5 版本。構建一個集群，包括三個 OSD, osd.0 osd.1 osd.2。

從客戶端發送 IO 寫操作 A，osd.0 是 primary, osd1/ 2 是 replica. 假設 osd.2 此時由于網絡或者硬盤故障，或者軟件 bug 掛了。此時 osd0 自己完成了本地寫，收到了 osd.1 的副本寫 ack, 還在等待 osd.2 的副本寫 ack. 在最長等待 osd_heartbeat_grace，默認是 20 秒后，利用心跳機制，會向 monitor 匯報此 osd 掛掉。此時集群會進入 peering, 在 peering 的時候，受影響的 pg,io 會被 block 住。這個時候詳細來看作為 primay 的 osd.0  如何處理寫操作 A。在 peering 之前，osd0 會調用 void ReplicatedPG::on_change(), 進一步調用 apply_and_flush_repops()

apply_and_flush_repops() 會將操作 A requeue 到 op_wq 里去。

等待 pg peering 完成后，A 操作的對象所屬的 pg 變成 active 狀態，IO 繼續，do_op 會繼續處理 IO 隊列，包括 requeue 的 A 操作。

do_op 會查詢 pglog, 發現 A 操作其實已經落盤，是個 dup 的操作，可直接返回 client.

對于兩個 osd , 如 osd.1/osd.2 都掛的情況，primary 還是會 requeue A 操作，但假如 pg min_size 是 2，這個時候由于只有 primay osd 在線，小于 min_size。

所以等 peering 完成，IO 也會被 block 住，等待數據恢復至 min_size 以上，IO 才會繼續。

同樣的，如果掛的是 primary osd.0, 分兩種情況，一種是 osd.0 先掛，然后 client 發送 A 操作，client 端會等一會兒，等到 peering 完成，client 拿到更新的 osdmap 后，重發請求，納悶剩下的 IO 處理跟正常情況一樣了。

第二種是 client 已經將請求發送到 primary osd.0, osd.0 也把副本寫操作發送到了 osd.1 和 osd.2 上，然后 osd.0 掛了。同樣等到心跳檢測到 osd.0 掛的情況，然后 peering. osd.1 也會有 equeue 的動作，等待 peering 完成后，假設 osd.1 變成了 primary, 那接下來的邏輯跟之前 primary osd.0 的動作一樣了。

關于“錯誤狀況下怎么保證 ceph IO 的一致性”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。