【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)令人沮喪。為什么會這樣？

[[185468]]

簡而言之：在任何擁有最終一致性特征的非關(guān)系數(shù)據(jù)庫架構(gòu)當(dāng)中，我們幾乎都不可能捕捉到具備一致性狀態(tài)的備份副本。而以此為基礎(chǔ)實(shí)現(xiàn)成功的數(shù)據(jù)恢復(fù)更是幾近不可能。

究其原因，首先應(yīng)考慮到分布式架構(gòu)的基本性質(zhì)。此類架構(gòu)旨在擴(kuò)展并抵御節(jié)點(diǎn)故障，盡可能降低停機(jī)機(jī)率。而在對分布式架構(gòu)進(jìn)行備份時，主要存在以下幾項(xiàng)挑戰(zhàn)：

• 數(shù)據(jù)被寫入至某一可用節(jié)點(diǎn)。數(shù)據(jù)的***著陸點(diǎn)無法預(yù)測，因此無法在數(shù)據(jù)被寫入節(jié)點(diǎn)的同時對其進(jìn)行捕捉。
• 此后，數(shù)據(jù)被復(fù)制到至少一個其它節(jié)點(diǎn)當(dāng)中，而后方進(jìn)行驗(yàn)證。這確保了有效寫入，同時亦立即為數(shù)據(jù)創(chuàng)建副本。
• 接下來將數(shù)據(jù)復(fù)制到更多節(jié)點(diǎn)中以實(shí)現(xiàn)可用性。這一步完成后，同一數(shù)據(jù)可快速連續(xù)進(jìn)行更新。
• 意味著任意時段同一數(shù)據(jù)都至少擁有3到4套副本。
• 且各節(jié)點(diǎn)始終不存在即時一致性。
• 如果對各套副本進(jìn)行分別備份，則效率明顯極為低下。
• 而在任一節(jié)點(diǎn)發(fā)生故障時，其拓?fù)浣Y(jié)構(gòu)也將立即發(fā)生變化。

在理論上，出色的DevOps團(tuán)隊能夠編寫對應(yīng)腳本，確保在80%到90%的時段內(nèi)成功實(shí)現(xiàn)數(shù)據(jù)庫備份（不過考慮到多節(jié)點(diǎn)故障、拓?fù)渥兏?shù)據(jù)庫壓縮等情況的存在，腳本編寫難度極大）。

然而遺憾的是，備份本身只是這一議程當(dāng)中較“容易”的部分。事實(shí)上，恢復(fù)才是問題的關(guān)鍵所在。成功的恢復(fù)機(jī)制要比大多數(shù)人想象中的復(fù)雜得多。其涉及以下具體流程：

• 重構(gòu)正確拓?fù)洹Ｓ捎诟鱾€節(jié)點(diǎn)皆單獨(dú)備份，因此數(shù)據(jù)庫必須恢復(fù)到與備份時對等的拓?fù)錉顟B(tài)（6節(jié)點(diǎn)對6節(jié)點(diǎn)，12節(jié)點(diǎn)對12節(jié)點(diǎn)），而其中必然涉及跨云環(huán)境、測試/開發(fā)與持續(xù)集成/持續(xù)交付等用例。
• 等待數(shù)據(jù)庫進(jìn)行修復(fù)與恢復(fù)。非關(guān)系數(shù)據(jù)庫體系能夠承受節(jié)點(diǎn)故障并保持正常運(yùn)行，然而這種具備數(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ū)存在，其會在運(yùn)行當(dāng)中不斷覆蓋自身內(nèi)容。有時候，我們甚至無法恢復(fù)必要的日志數(shù)據(jù)以實(shí)現(xiàn)數(shù)據(jù)庫協(xié)調(diào)。
• 并不具備可靠的方法以返回某時間點(diǎn)。即使使用oplog數(shù)據(jù)，我們?nèi)匀缓茈y重建特定時間點(diǎn)數(shù)據(jù)。在最理想的情況下，大家只會獲得一套時間點(diǎn)較近且相對精確的數(shù)據(jù)庫副本。

在現(xiàn)實(shí)世界當(dāng)中，即使數(shù)據(jù)能夠得到恢復(fù)，整個周期也可能需要數(shù)天乃至數(shù)周。然而最近GitLab由于誤刪導(dǎo)致主數(shù)據(jù)庫數(shù)據(jù)丟失的事故證明，即使技術(shù)水平極高的組織機(jī)構(gòu)也很難順利處理這一難題。而如果缺少可靠的備份與恢復(fù)流程，人為錯誤有可能與自然災(zāi)害一樣對數(shù)據(jù)庫產(chǎn)生致命影響。

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】