為什麼備份對于超大規模應用和分布式體系結構來說很困難

之前，我們讨論了如何為新時代的雲原生應用重新設計備份，以及您應該在現代資料庫備份和恢複解決方案中尋找什麼。 但是，即使您放棄了傳統的備份方法并編寫腳本來處理任務，下一代應用程式和資料庫(Apache Cassandra、MongoDB、Amazon DynamoDB、微軟DocumentDB、Apache HBase等)的備份和恢複都非常困難。 但是為什麼呢？

簡而言之，在最終一緻的随處可寫非關系資料庫架構中，幾乎不可能捕獲一緻的狀态備份。 成功恢複資料的可能性更小！

出現這種情況的原因不止一個。 這可以歸結為分布式體系結構的基本特性，該體系結構旨在擴充和承受節點故障而不停機。 正如我們在下面強調的，從一開始就有幾個挑戰使得備份分布式體系結構變得困難:

• 資料被寫入可用節點。 資料的第一個着陸點是不可預測的，是以當資料到達節點時，沒有辦法捕捉到它。
• 然後，在驗證之前，将資料複制到至少一個其他節點。 這確定了有效的寫入，但也立即建立了資料的副本。
• …然後複制到一個或兩個以上的節點，以實作可用性。 這發生在之後，同樣的資料可以快速連續更新。
• …意味着任何時候都有3或4份資料拷貝。
• ……節點永遠不會立即保持一緻。
• …而且備份效率非常低，因為每個副本都被拷貝。
• 當一個節點發生故障時，拓撲結構會在中途發生變化。

從理論上講，一個好的DevOps團隊可能能夠編寫腳本，在80%到90%的時間内成功備份資料庫資料同步 (像多節點故障、拓撲結構變化、資料庫壓縮等情況都很複雜，是以腳本很難正确執行)。

不幸的是，備份是等式中“簡單”的部分。 恢複備份才是真正具有挑戰性的地方。 成功的恢複比大多數人想象的要複雜得多。 它包括以下步驟:

• 重建正确的拓撲。 因為每個節點都是單獨備份的，是以資料庫必須恢複到相同的拓撲結構(6個節點到6個節點，12個節點到12個節點)，等等。 這涉及到跨雲、測試/開發和配置項/CD光牒用例實作恢複。
• 等待資料庫修複并恢複自身。 非關系資料庫體系結構可以承受節點故障并保持運作，但是帶有資料協調的完全恢複将會在慢速驅動器上恢複最差的磁盤陣列重建的記憶。
• 對多個不一緻的副本進行重複資料消除。 備份副本包含3個或更多可能處于不一緻狀态的所有資料的副本。 首先需要對其進行重複資料消除或協調。
• 但是資料曆史并不總是可用的。 在大多數分布式體系結構中，oplog是一個循環緩沖區，它在運作時會自我吞噬！ 甚至可能無法恢複必要的日志資料來協調資料庫。
• 沒有可靠的方法可以回到某個時間點。 即使使用oplog資料，也很難重建時間點資料。 充其量，你會得到一個最近的，最準确的資料庫副本。

在現實世界中，恢複可能需要幾天或幾周的時間——如果資料可以恢複的話。 但是正如最近Gitlab的中斷所顯示的，即使是精通技術的組織也很難把它做好。 如果沒有可靠的備份和恢複過程，人為錯誤對資料庫來說就像自然災害一樣緻命。