OpenStack Swift Replication

Replication 當發生網絡故障和驅動器故障等問題時，保持系統的一致性，一樣翻譯自官方文檔。

Replication 複製

因爲每個副本在swift中功能獨立，客戶端一般只須要一個簡單多數的節點響應爲操做成功，短暫的故障像是網絡，虛節點快速形成副本產生分歧。這些不一樣最終經過異步，端到端的replicator進程來進行響應。replicator進程遍歷本地的文件系統，同時以平衡的方式執行在物理磁盤上。

複製使用推動模式，記錄和文件只是拷貝從本地到遠端的副本。這很重要由於在節點上的數據可能不屬於那些（在切換和環改變的模式下），replicator不能知道應該引入的在其餘地方存在集羣的數據。這是全部節點的責任去包含數據來確保數據到達屬於的地方。副本放置由ring處理。

在系統中每個文件或者記錄的刪除被記錄成一個墓碑。，以便於刪除能夠再建立的時候複製。這些墓碑經過複製進程清除在一段時間後被稱做一致性窗口。與複製持續和從集羣中移除節點的短暫故障的時間有關。墓碑
清除應該與replcation管理來到達副本集中。

若是replicator檢測一個遠端的驅動器故障，它將會使用ring的"get_more_nodes"結構來選擇交換節點進行同步。replicator能夠維護須要的複製級別來面對磁盤故障。儘管有些副本或許再也不一個當即可用的位置。replicator不會維護須要的複製級別在其餘的故障（整個節點故障）由於大多數的故障時短暫的。

複製是一個很活躍的開發領域，在速度很正確性上有潛在的提供的能力。

有兩種主要的replicator類型-db replicator,能夠複製帳戶和容器，object replicator 能夠複製對象數據。

DB Replication 

db複製執行的第一步是一個低消耗的哈希比較用來找出是否兩個符文已經匹配過了。在常規的操做下。這個檢查能夠很是快覈實系統中多數的數據庫已經同步。若是哈希值不一樣，replicator經過共享最後一次的同步點以後增長的記錄對數據庫進行同步。

這個同步點是一個高水印標記的用來記錄在哪兩個數據庫進行了同步，而後存儲在每一個數據庫中做爲一個遠程數據庫id和記錄id的元組。數據庫id在數據庫全部副本中是惟一的，記錄id是遞增的整數。畢竟新的記錄已經推送到遠端的數據庫上，整個本地數據庫同步表被推送，所以遠端數據可知道如今於任何本地數據庫以前的同步的數據庫進行了同步了。

若是一個副本被發現徹底的丟失了，整個本地數據庫文件使用rsync(1)傳送到對等的節點的遠端數據庫，授予一個新的惟一的id。

實際上，DB複製能夠處理上百個數據庫能夠設定沒併發每秒的值（取決於能夠用的CPU和磁盤的數量）而且必須執行DB是事務的約束。

Object Replication 對象複製

最初的對象複製的實現 簡單執行了rsync推送數據從本地虛節點到全部它所指望的遠端的服務器。儘管在小規模下執行的很充分，複製時間飆升一旦目錄結構再也不保存在RAM中。咱們如今使用這個種方式的改進版本，將每個後綴目錄的內容的哈希值保存到每個虛節點的哈希文件中，當目錄後綴的內容被修改時，它的哈希值無效。

對象複製進程獨缺這些哈希文件，計算出實效的哈希，而後傳送這些哈希到每個遠端的有虛節點的服務器，只是有不一樣哈希值的後綴目錄在遠端服務器被rsync。在推送文件到遠端服務器以後，複製進程修改它從新計算rsync的後綴目錄的哈希值。

對象複製的性能一般被要遍歷的未緩存目錄的數量所限制，一般做爲失效後綴目錄哈希值的結果。在咱們運行的系統中使用寫卷和虛幾點計數，它被設計以便於2%的哈希空間在一個節點上將失效天天，已經在實驗中給予咱們能夠接受的複製速度。