EBS的Cassandra備份

Question

目前，我正在尋找如何在Cassandra中完成備份/還原。 我們在AWS中設置了一個三節點集群。 我知道使用nodetool快照工具可以拍攝快照，但是過程有些繁瑣。

我的想法是：使用EBS快照，因為它們更耐用且易於設置，但是我發現EBS的一個問題是不一致備份。 因此，我的計划是在拍攝EBS快照之前運行一個腳本，該腳本將運行flush命令以清空所有內存表數據並將其復制到磁盤（SSTable）上，然后准備帶有刷新后的sstable的硬鏈接。 完成之后，啟動EBS快照，這是我們可以解決如果僅使用EBS snapshost可能遇到的不一致問題。

如果您發現此方法有任何問題或分享您的建議，請告訴我。

Answer 1

毫無疑問，SSTables在備份方面確實提供了很多幫助。

對於集群中一切正常的情況，您的想法聽起來不錯。 實際上，Cassandra是一致性可配置的（如果我說最終是一致的，那么可能有人在這里冒犯了，呵呵），而且由於系統本身在給定的時間可能不完全一致，因此您不能說備份也是如此。 但是，另一方面，Cassandra（和NoSQL模型）的優點之一是它恢復得很好，這在大多數情況下都是正確的（與關系數據庫相對，后者對數據丟失非常敏感） ）。 如果您至少擁有完全保留的SSTables文件，則最終不會獲得一堆無用的數據。

請注意，EBS快照是塊級的。 因此，當您在其上具有文件系統時，這也可能是一個問題。 幸運的是，現在任何現代文件系統都具有日志記錄並且非常可靠，因此這不成問題，但是將數據放在單獨的分區中是一個好習慣，因此，在完全刷新后立即有其他人在其中寫入數據的可能性很大。較小。

當您最終需要還原集群時，可能會丟失一些副本，從而要求您運行nodetool repair ，如果您之前做過，那會很痛苦，並且需要大量時間來處理大量數據。 （但是，無論如何，建議定期進行修復 ，特別是如果您刪除很多內容。）

需要考慮的另一件事是暗示的切換 （缺少行所有者的寫入，但其他節點將保留這些寫入，直到所有者返回為止）。 我不知道在刷新時它們會發生什么，但是我想它們僅保留在內存中並且僅在提交日志中。

並且，當然，請完全還原，然后再假定將來會起作用。

我在Cassandra方面經驗不多，但是我聽說的有關備份解決方案的地方是另一個區域或數據中心中的整個群集副本，而不是快照之類的冷備份。 與您嘗試執行的原始磁盤快照相比，它可能更昂貴，但也更可靠。

Answer 2

我不確定節點的備份有什么幫助，因為在C *中，數據已經備份在副本節點中。

如果某個節點已死並且必須更換，則新節點將從其需要擁有的其他節點中了解數據，並從其他節點獲取數據，因此您可能不需要從磁盤備份中還原。

像下面這樣的復制方案會有所幫助嗎？ 使用兩個數據中心（DC：A有3個節點）（DC：B有1個節點），RF為（A：2＆B：1）。 允許客戶端與DC：A中的節點進行交互，且讀/寫一致性為Local_QUORUM。 在這里，由於2中達到定額，所有讀取和寫入都將成功，並且您將在DC：B上復制數據。 現在您可以備份DC：B