cassandra節點上的常規節點工具修復的目的

Question

我正在通過文檔和自我節奏的視頻課程進行工作，因此請耐心等待。

建議每個節點都經常運行nodetool repair，不清楚的是爲什麼。

當您進行寫入操作時，協調器會將請求發送到主令牌持有者節點以及其他副本。假設所有節點都處於運行狀態，則所有節點應在短時間內同步。我假設刪除和更新都以與插入相同的方式工作，並添加了用於刪除的邏輯刪除標記。

因此，在一個完美的情況下，沒有任何節點出現故障，網絡延遲很小，運行nodetool repair的優勢是什麼？

在節點做下去一個現實的情況下，運行nodetool repair允許擊落節點重新同步在切換提示已過期。

在什麼情況下可以數據復活？它僅僅是一個節點長度比gc_grace_period長的地方？或者這真的是網絡延遲可能很大的問題？

而且，你如何有效地安排每個節點上的工作，使他們不重疊？它必須隨着集羣大小的改變而動態調度，並且你大概不知道要花多長時間。

謝謝。

Answer 1

假設沒有故障，運行修理是可選的。

• 卡桑德拉維基注意到，如果失敗不發生，你可以通過HintedHandoff。 https://wiki.apache.org/cassandra/Operations#Repairing_missing_or_inconsistent_data
• Datastax也對此進行了擴展;如果你只是通過TTL刪除並且同步時間，那麼我想不必擔心墓碑和gc_grace_seconds + max_hint_window。 http://www.datastax.com/dev/blog/advanced-repair-techniques

話雖如此，卡桑德拉的設計假設會發生某種失敗;當在商品硬件上運行時，一些事情總是會打破。

在調度維修條款，以免「重疊」，我假設你的意思是想查詢的是正在修理範圍時，以儘量減少性能下降：

• 使用連續修補（每個副本依次修復）而不是並行（其中所有節點的Merkle樹都是在同一時間構建的）。然而，這種順序會在每次生成快照時進行權衡，並且不會盡快完成整個過程。
• 使用增量修復（儘管這會對你的壓制策略的影響）
• 您還可以控制是否修復應該在一個特定的DC運行或羣集範圍