Cassandra 數據修復

 

關於維修

隨着時間的流逝，由於數據庫的分布式性質，副本中的數據可能會與其他副本不一致。節點修復可糾正不一致之處，以使所有節點具有相同且最新的數據。對於Apache Cassandra™（DDAC） 群集的每個DataStax分發，節點修復都是定期維護的重要組成部分。使用數據庫設置或各種工具來配置每種修復類型。

Cassandra提供以下修復過程。以下鏈接詳細說明了何時使用以及如何配置每種修復類型。

 

 

Hinted Handoff （提示移交）（在寫入時進行修復）

如果節點變得無法接收特定的寫入，則寫入的協調器節點會將要寫入的數據保留為一組提示。當節點重新聯機時，協調器會移交提示，以便節點可以趕上所需的寫入。

 

有時，節點在寫入數據時變得無響應。無法響應的原因包括硬件問題，網絡問題或出現長時間垃圾回收（GC）暫停的過載節點。通過設計，提示切換從本質上允許Apache Cassandra™（DDAC）的DataStax Distribution繼續執行相同數量的寫操作，即使集群以減少的容量運行時也是如此。

如果故障檢測器將節點標記為已關閉並且在cassandra.yaml文件中啟用了 提示切換，則協調器節點會在一段時間內存儲丟失的寫入。提示包含以下信息：

• 發生故障的節點的目標ID
• 提示ID，它是數據的時間UUID
• 標識Cassandra 版本的消息ID
• 數據本身為斑點

提示每十秒鍾刷新一次到磁盤上，從而減少了提示的陳舊性。當八卦發現節點重新聯機時，協調器將重播每個剩余的提示，以將數據寫入新返回的節點，然后刪除提示文件。如果節點關閉的時間超過max_hint_window_in_ms參數中配置的值（默認為三個小時），則協調器將停止編寫新提示。

協調器還每隔十分鍾檢查一次提示，這些提示對應於在中斷期間過短而導致故障檢測程序無法通過八卦注意到的超時超時的寫​​入。如果副本節點過載或不可用，並且故障檢測器尚未將該節點標記為已關閉，則在write_request_timeout_in_ms（默認為2秒）觸發的超時后，對該節點的大多數或所有寫入都會失敗。協調器返回TimeOutException錯誤，並且寫入將失敗。但是，將存儲提示。如果多個節點同時經歷短暫中斷，則協調器上可能會累積大量內存壓力。協調器跟蹤它當前正在編寫多少個提示。如果提示的數量增加太多，則協調器將拒絕寫入並拋出提示。OverloadedException 錯誤。

一致性等級ONE

該一致性水平寫入請求的數量會影響是否寫入提示，並且寫入請求隨后會失敗。如果群集由復制因子為1的兩個節點A和B組成，則每一行僅存儲在一個節點上。假設節點A是協調器，但是在一致性級別為ONE的行K寫入到節點K之前發生故障。在這種情況下，無法滿足指定的一致性級別，並且由於節點A是協調者，因此它無法存儲提示。節點B無法寫入數據，因為它尚未作為協調者接收到數據，並且尚未存儲提示。如果無法滿足客戶端指定的一致性級別，則協調器將檢查已啟動且不會嘗試寫入提示的副本數。在這種情況下，協調器將返回一個UnavailableException錯誤。寫入請求失敗，並且提示未寫入。

通常，建議在群集中具有足夠的節點，並使用足夠多的復制因子來避免寫入請求失敗。例如，考慮一個由三個節點A，B和C組成的群集，其復制因子為3。當將行K寫入協調器（在這種情況下為節點A）時，即使節點C發生故障，也可以滿足ONE或QUORUM的一致性級別。為什么？節點A和B都將接收數據，因此符合一致性級別要求。將為節點C存儲提示，並在節點C出現時寫入提示。同時，協調器可以確認寫入成功。

 

 

一致性級別ANY

對於希望當所有正常副本都關閉並且無法滿足一致性級別ONE時Cassandra接受寫入的應用程序，數據庫提供了一致性級別ANY。在適當的副本目標可用並收到提示重播之后，ANY保證寫入是持久且可讀的。

死亡的節點可能已經存儲了未傳遞的提示，因為任何節點都可以是協調者。長時間中斷后，死節點上的數據將過時。如果節點已關閉很長時間，請運行手動修復。

乍看之下，暗示的切換似乎消除了手動修復的需要，但這不是事實，因為硬件故障是不可避免的，並且具有以下后果：

• 丟失必要的歷史數據以准確告訴集群的其余部分缺少哪些數據。
• 失敗節點協調的請求丟失了尚未提示的提示。

通過停用節點或使用nodetool removenode命令從集群中刪除節點時，數據庫會自動刪除針對不再存在的節點的提示，並刪除已刪除表的提示。

有關提示存儲的更多說明，請參閱3.0版Cassandra的新功能：改進的提示存儲和交付博客文章。有關基本信息，請參閱現代提示的切換博客文章。

 

 

 

Read Repair （讀修復）（讀取數據時進行修復）

在讀取路徑期間，查詢將匯總來自多個節點的數據。 讀取的協調器節點比較來自每個副本節點的數據。 如果任何副本節點的數據已過時，則協調器節點會向其發送最新版本。 此類修復的范圍取決於密鑰空間的復制因子。 在讀取期間，數據庫僅收集足以滿足復制因子的副本數據，並且僅對參與該讀取操作的節點執行讀取修復。

 

當在一致性水平大於讀取查詢遇到不一致的結果  ONE 或者 LOCAL_ONE ， Apache的卡桑德拉DataStax分布™（DDAC）開始讀修復。此類讀取修復在前台運行，並阻止應用程序操作，直到修復過程完成。

注意：一致性級別為ONE或 LOCAL_ONE不阻止應用程序操作的讀取查詢，因為必須存在數據不匹配才能觸發讀取修復，並且由於僅查詢一個副本，因此不會進行比較，因此不會發生不匹配。

更詳細地：

1. 該協調器節點請求數據和其他一個副本的消化他們的數據。
2. 如果從副本返回給協調器的數據不匹配，則從查詢中涉及的所有副本中請求讀取（由一致性級別決定），然后合並結果。
3. 如果單個副本沒有每列的所有最新數據，則通過混合和匹配來自不同副本的列來組合一條新記錄。
4. 確定最新版本后，記錄將僅寫回請求中涉及的副本。

例如，對於 LOCAL_QUORUM 具有三倍復制因子的讀取，將查詢兩個副本，因此僅修復這兩個副本。

注意：讀取修復不會傳播過期的邏輯刪除，也不會在實際修復數據時考慮過期的邏輯刪除。這意味着，如果有邏輯刪除的數據在gc_grace_seconds過期之前尚未傳播到所有副本節點 ，則該數據可能會繼續作為實時數據返回。

對於5.1.12之前的DDAC版本，還可以配置群集范圍和本地數據中心的非阻塞后台修復，並由參數控制 dclocal_read_repair_chance，read_repair_chance 如table_options中所述。

更詳細地：

1. 如果表的讀取修復機會屬性不為零，則在每次查詢期間， Cassandra都會在0.0和之間生成一個隨機數1.0。
2. 如果該隨機數小於或等於 read_repair_chance，則啟動非阻塞全局讀取修復。
3. 如果不是，則Cassandra進行測試以查看隨機數是否小於或等於 dc_local_read_repair_chance，如果是，則僅在本地DC中執行無阻塞讀取修復。

注意： Cassandra對讀取修復測試和全局讀取修復均使用單個隨機值 read_repair_chance，首先對其進行評估。如果 read_repair_chance大於或等於給 dclocal_read_repair_chance定表，則永遠不會進行本地DC讀取修復。

由於檢查DTCS壓縮中使用的時間戳的方法，因此無法對使用DateTieredCompactionStrategy（DTCS）-已過時的表執行讀修復。如果表使用 DateTieredCompactionStrategy，則設置 read_repair_chance為零。對於其他壓縮策略， read_repair_chance通常將其設置為0.2。

 

 

 

Anti-entropy repair （逆熵）

Cassandra提供了nodetool修復工具，以確保各個副本之間的數據一致性。它比較所有副本中的數據，然后將數據更新為最新版本。使用nodetool repair為您的定期維護的一部分。

重要信息： DataStax建議在拓撲更改期間停止修復操作；維修服務會自動執行此操作。涉及移動范圍時，拓撲更改期間進行的維修可能會出錯。

逆熵節點修復對於Apache Cassandra™（DDAC）群集的每個DataStax分發都很重要。頻繁的數據刪除和關閉的節點是導致數據不一致的常見原因。將逆熵修復用於日常維護，以及在群集需要通過運行nodetool修復進行修復時。

在此頁：

• 逆熵修復如何工作？
• 順序維修與並行維修

逆熵修復如何工作？

Cassandra使用Merkle樹完成了逆熵修復，Merkle樹是二進制哈希樹，其葉子是各個鍵值的哈希值（類似於Dynamo和Riak）。逆熵是比較所有副本的數據並將每個副本更新為最新版本的過程。Cassandra的流程分為兩個階段：

1. 為每個副本構建一個Merkle樹
2. 比較Merkle樹以發現差異

Cassandra Merkle樹的葉子是行值的哈希。樹中較高的每個父節點是其各自子節點的哈希。由於Merkle樹中的較高節點表示數據在樹的更下方，因此Casandra可以獨立檢查每個分支，而無需協調器節點下載整個數據集。為了進行反熵修復，Cassandra使用了深度為15（2 15 = 32K葉節點）的緊湊樹版本。例如，對於包含一百萬個分區和一個損壞的分區的節點，流式傳輸大約30個分區，這是落在樹的每個葉子中的數量。Cassandra與較小的Merkle樹配合使用，因為它們需要較少的存儲內存，並且在比較過程中可以更快地傳輸到其他節點。

 

 

在啟動節點從參與的對等節點接收到Merkle樹之后，啟動節點將每棵樹與其他所有樹進行比較。如果檢測到差異，則不同的節點將交換沖突范圍的數據，並將新數據寫入SSTables。比較從Merkle樹的頂部節點開始。如果未檢測到差異，則無需修復數據。如果檢測到差異，則處理進行到左子節點並進行比較，然后比較右子節點。當發現一個節點不同時，與該節點有關的范圍存在不一致的數據。與該Merkle樹節點下的葉子對應的所有數據將被新數據替換。對於任何給定的副本集，Cassandra 一次僅對一個副本執行驗證壓縮。

Merkle樹的構建需要大量資源，從而增加了磁盤I / O並占用了內存。此處討論的某些選項有助於減輕對群集性能的影響。

nodetool repair如果未指定節點，請在指定的節點或所有節點上運行命令。啟動修復的節點成為操作的協調器節點。為了構建Merkle樹，協調器節點確定具有匹配數據范圍的對等節點。在對等節點上觸發主壓縮或驗證壓縮。驗證壓縮會讀取並為存儲的列族中的每一行生成一個哈希，然后將結果添加到Merkle樹中，然后將該樹返回到發起節點。默克爾樹使用數據的哈希值，因為通常，哈希值將小於數據本身。將在卡桑德拉修復博客中詳細討論了這個過程。

注意：要從增量修復切換到完全修復，請參閱更改修復策略。

順序維修與並行維修

順序修復在另一個節點上執行操作。並行修復可同時修復具有相同副本數據的所有節點。數據中心並行（-dc-par）通過在所有數據中心中同時運行順序修復來組合順序和並行。每個數據中心中的一個節點將運行修復，直到修復完成。

順序修復為每個副本拍攝快照。快照是到現有SSTables的硬鏈接。它們是不可變的，幾乎不需要磁盤空間。在修復過程中，快照處於活動狀態，然后數據庫將其刪除。當協調器節點在Merkle樹中發現差異時，協調器節點將根據快照進行必要的修復。例如，對於復制因子為3（RF = 3）且副本A，B和C的鍵空間中的表，修復命令立即獲取每個副本的快照，然后從快照中依次修復每個副本（使用快照） A修復副本B，然后快照A修復副本C，然后快照B修復副本C）。

並行修復可同時為所有數據中心中的所有節點構造Merkle表。它可以同時在節點A，B和C上工作。在並行修復期間，動態竊聽將使用未經修復的快照中的副本來處理對該表的查詢。使用並行修復可以快速完成修復，也可以在出現操作性停機時允許在修復期間完全消耗資源的情況下使用修復。

與順序修復不同，數據中心並行修復可同時為所有數據中心構造Merkle表。因此，不需要（或生成）快照。