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