建站
咨詢
售后
建站咨詢
新聞中心
云原生應用時代下，對備份體系進行調整無疑已經成為一種必然。然而，即使逐步淘汰了原有備份與負責處理相關任務的腳本，大家仍會發(fā)現各類下一代應用程序及數據庫（包括Apache Cassandra、MongoDB、Amazon DynamoDB、微軟DocumentDB、Apache HBase等等）在備份與恢復方面的表現令人沮喪。為什么會這樣？
成都創(chuàng)新互聯公司2013年開創(chuàng)至今，是專業(yè)互聯網技術服務公司，擁有項目成都做網站、網站建設、外貿營銷網站建設網站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元調兵山做網站,已為上家服務,為調兵山各地企業(yè)和個人服務,聯系電話:18980820575
簡而言之：在任何擁有最終一致性特征的非關系數據庫架構當中，我們幾乎都不可能捕捉到具備一致性狀態(tài)的備份副本。而以此為基礎實現成功的數據恢復更是幾近不可能。
究其原因，首先應考慮到分布式架構的基本性質。此類架構旨在擴展并抵御節(jié)點故障，盡可能降低停機機率。而在對分布式架構進行備份時，主要存在以下幾項挑戰(zhàn)：
- 數據被寫入至某一可用節(jié)點。數據的***著陸點無法預測，因此無法在數據被寫入節(jié)點的同時對其進行捕捉。
- 此后，數據被復制到至少一個其它節(jié)點當中，而后方進行驗證。這確保了有效寫入，同時亦立即為數據創(chuàng)建副本。
- 接下來將數據復制到更多節(jié)點中以實現可用性。這一步完成后，同一數據可快速連續(xù)進行更新。
- 意味著任意時段同一數據都至少擁有3到4套副本。
- 且各節(jié)點始終不存在即時一致性。
- 如果對各套副本進行分別備份，則效率明顯極為低下。
- 而在任一節(jié)點發(fā)生故障時，其拓撲結構也將立即發(fā)生變化。
在理論上，出色的DevOps團隊能夠編寫對應腳本，確保在80%到90%的時段內成功實現數據庫備份（不過考慮到多節(jié)點故障、拓撲變更、數據庫壓縮等情況的存在，腳本編寫難度極大）。
然而遺憾的是，備份本身只是這一議程當中較“容易”的部分。事實上，恢復才是問題的關鍵所在。成功的恢復機制要比大多數人想象中的復雜得多。其涉及以下具體流程：
- 重構正確拓撲。由于各個節(jié)點皆單獨備份，因此數據庫必須恢復到與備份時對等的拓撲狀態(tài)（6節(jié)點對6節(jié)點，12節(jié)點對12節(jié)點），而其中必然涉及跨云環(huán)境、測試/開發(fā)與持續(xù)集成/持續(xù)交付等用例。
- 等待數據庫進行修復與恢復。非關系數據庫體系能夠承受節(jié)點故障并保持正常運行，然而這種具備數據協(xié)調能力的架構在恢復方面則表現糟糕，特別是在配合低速存儲驅動器的情況下。
- 重復數據刪除引發(fā)多套不一致版本。備份副本可能擁有三套甚至更多處于不一致狀態(tài)的全部數據副本，因此需要首先進行重復數據刪除或者一致化處理。
- 數據歷史并非始終可用。在大多數分布式架構當中，oplog都作為循環(huán)緩沖區(qū)存在，其會在運行當中不斷覆蓋自身內容。有時候，我們甚至無法恢復必要的日志數據以實現數據庫協(xié)調。
- 并不具備可靠的方法以返回某時間點。即使使用oplog數據，我們仍然很難重建特定時間點數據。在最理想的情況下，大家只會獲得一套時間點較近且相對精確的數據庫副本。
在現實世界當中，即使數據能夠得到恢復，整個周期也可能需要數天乃至數周。然而最近GitLab由于誤刪導致主數據庫數據丟失的事故證明，即使技術水平極高的組織機構也很難順利處理這一難題。而如果缺少可靠的備份與恢復流程，人為錯誤有可能與自然災害一樣對數據庫產生致命影響。
【譯稿，合作站點轉載請注明原文譯者和出處為.com】
新聞標題：我們?yōu)楹魏茈y對超大規(guī)模應用與分布式架構進行備份？
本文網址：http://m.fisionsoft.com.cn/article/coiosco.html
