云原生應(yīng)用時(shí)代下，對備份體系進(jìn)行調(diào)整無疑已經(jīng)成為一種必然。然而，即使逐步淘汰了原有備份與負(fù)責(zé)處理相關(guān)任務(wù)的腳本，大家仍會(huì)發(fā)現(xiàn)各類下一代應(yīng)用程序及數(shù)據(jù)庫（包括Apache Cassandra、MongoDB、Amazon DynamoDB、微軟DocumentDB、Apache HBase等等）在備份與恢復(fù)方面的表現(xiàn)令人沮喪。為什么會(huì)這樣？

成都創(chuàng)新互聯(lián)公司2013年開創(chuàng)至今，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都做網(wǎng)站、網(wǎng)站建設(shè)、外貿(mào)營銷網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢想脫穎而出為使命，1280元調(diào)兵山做網(wǎng)站,已為上家服務(wù),為調(diào)兵山各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18980820575

簡而言之：在任何擁有最終一致性特征的非關(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)行備份時(shí)，主要存在以下幾項(xiàng)挑戰(zhàn)：

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

在理論上，出色的DevOps團(tuán)隊(duì)能夠編寫對應(yīng)腳本，確保在80%到90%的時(shí)段內(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ù)?。由于各個(gè)節(jié)點(diǎn)皆單獨(dú)備份，因此數(shù)據(jù)庫必須恢復(fù)到與備份時(shí)對等的拓?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)糟糕，特別是在配合低速存儲(chǔ)驅(qū)動(dòng)器的情況下。
• 重復(fù)數(shù)據(jù)刪除引發(fā)多套不一致版本。備份副本可能擁有三套甚至更多處于不一致狀態(tài)的全部數(shù)據(jù)副本，因此需要首先進(jìn)行重復(fù)數(shù)據(jù)刪除或者一致化處理。
• 數(shù)據(jù)歷史并非始終可用。在大多數(shù)分布式架構(gòu)當(dāng)中，oplog都作為循環(huán)緩沖區(qū)存在，其會(huì)在運(yùn)行當(dāng)中不斷覆蓋自身內(nèi)容。有時(shí)候，我們甚至無法恢復(fù)必要的日志數(shù)據(jù)以實(shí)現(xiàn)數(shù)據(jù)庫協(xié)調(diào)。
• 并不具備可靠的方法以返回某時(shí)間點(diǎn)。即使使用oplog數(shù)據(jù)，我們?nèi)匀缓茈y重建特定時(shí)間點(diǎn)數(shù)據(jù)。在最理想的情況下，大家只會(huì)獲得一套時(shí)間點(diǎn)較近且相對精確的數(shù)據(jù)庫副本。

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

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

文章標(biāo)題：我們?yōu)楹魏茈y對超大規(guī)模應(yīng)用與分布式架構(gòu)進(jìn)行備份？
分享URL：http://uogjgqi.cn/article/coiosco.html