網(wǎng)上有很多關(guān)于pos機(jī)備份電池電量低,從爐石傳說數(shù)據(jù)庫(kù)故障看云數(shù)據(jù)備份策略的知識(shí)，也有很多人為大家解答關(guān)于pos機(jī)備份電池電量低的問題，今天pos機(jī)之家(www.dsth100338.com)為大家整理了關(guān)于這方面的知識(shí)，讓我們一起來(lái)看下吧!
本文目錄一覽：
pos機(jī)備份電池電量低
前言最近爐石傳說的數(shù)據(jù)庫(kù)故障在業(yè)界傳得沸沸揚(yáng)揚(yáng)。無(wú)論故障起因是掉電宕機(jī)還是人為失誤，最終的影響是極其惡劣的，造成了無(wú)法挽回的數(shù)據(jù)丟失。對(duì)于越是大規(guī)模的數(shù)據(jù)庫(kù)系統(tǒng)，如何設(shè)計(jì)一個(gè)可靠的備份系統(tǒng)越是至關(guān)重要。本文主要以UCloud云數(shù)據(jù)庫(kù)產(chǎn)品UDB的備份系統(tǒng)為例，闡述下在海量數(shù)據(jù)庫(kù)情況下，備份系統(tǒng)該如何設(shè)計(jì)，如何確保備份的安全性，如何避免數(shù)據(jù)庫(kù)從刪庫(kù)到跑路的窘境。
大型備份系統(tǒng)設(shè)計(jì)
大型備份系統(tǒng)設(shè)計(jì)考慮因素如果一個(gè)DBA只需要維護(hù)一套數(shù)據(jù)庫(kù)，那么備份和恢復(fù)無(wú)疑是較為簡(jiǎn)單的，通常只需要知道怎么使用備份工具進(jìn)行備份和還原就搞定了。而在大公司中，數(shù)據(jù)庫(kù)實(shí)例數(shù)量往往都是成百上千個(gè)，公有云服務(wù)商甚至需要維護(hù)著十萬(wàn)級(jí)別的實(shí)例數(shù)量，簡(jiǎn)單粗糙的備份系統(tǒng)就顯得有些low了，設(shè)計(jì)一個(gè)完善的備份系統(tǒng)尤其關(guān)鍵。一個(gè)大體量的備份系統(tǒng)需要考慮好這幾個(gè)方面：如何根據(jù)業(yè)務(wù)類型選擇備份方式，邏輯備份or物理備份?如何靈活地設(shè)置備份策略，比如備份周期選擇，是否在從庫(kù)備份，備份上傳到何處如何確認(rèn)備份是否成功，哪一步驟出了問題如何確認(rèn)成功的備份實(shí)際可有效還原需要恢復(fù)時(shí)，如何做到一鍵恢復(fù)到指定時(shí)間點(diǎn)備份系統(tǒng)設(shè)計(jì)架構(gòu)下面以UCloud UDB為例，講述備份系統(tǒng)的一般設(shè)計(jì)架構(gòu)，來(lái)解決上述問題和需求。
UDB備份系統(tǒng)架構(gòu)設(shè)計(jì)如下圖所示：
其中Access模塊是業(yè)務(wù)接入模塊。它處理所有來(lái)自API或控制臺(tái)的備份相關(guān)請(qǐng)求，并將請(qǐng)求轉(zhuǎn)發(fā)到對(duì)應(yīng)的實(shí)際物理機(jī)去執(zhí)行備份或者恢復(fù)操作；備份機(jī)集群實(shí)際存放備份文件，它可能是獨(dú)立的物理機(jī)集群，也可能是NFS等其他存儲(chǔ)媒介，甚至是大規(guī)模分布式存儲(chǔ)。
在DB物理機(jī)上進(jìn)行的備份完成后，備份系統(tǒng)會(huì)通過復(fù)雜的負(fù)載均衡算法把備份上傳到合適的備份節(jié)點(diǎn)上。以保證對(duì)應(yīng)的備份相對(duì)均勻地分布在備份機(jī)集群上。
“備份元數(shù)據(jù)”大型備份系統(tǒng)的核心之一，是”備份元數(shù)據(jù)”的結(jié)構(gòu)設(shè)計(jì)。備份系統(tǒng)通過與“備份元數(shù)據(jù)”所在的業(yè)務(wù)數(shù)據(jù)庫(kù)交互，來(lái)決定備份的各種配置。
所謂“備份元數(shù)據(jù)”，即每個(gè)數(shù)據(jù)庫(kù)實(shí)例的備份信息，包括該實(shí)例的信息，備份的設(shè)置策略，備份結(jié)果的詳細(xì)信息等。通過這個(gè)數(shù)據(jù)庫(kù)備份系統(tǒng)將備份元數(shù)據(jù)和常用的與備份相關(guān)的流程串通起來(lái)。
通常來(lái)說，為了能夠存儲(chǔ)上述的“備份元數(shù)據(jù)”，一個(gè)海量的備份系統(tǒng)大致需要這樣做表設(shè)計(jì)：一張表A存放實(shí)例的備份配置信息，一張表B存放所有實(shí)例的詳細(xì)備份記錄。表A和表B通過該數(shù)據(jù)庫(kù)實(shí)例的唯一ID從業(yè)務(wù)上關(guān)聯(lián)起來(lái)。一般這兩張表所要保存的一些信息如下圖所示。
結(jié)合備份系統(tǒng)表設(shè)計(jì)和備份系統(tǒng)架構(gòu)設(shè)計(jì)圖，大多數(shù)跟備份相關(guān)的業(yè)務(wù)流程就可以更加自動(dòng)化可配置化。
A表使得每一個(gè)DB的實(shí)例的備份都可以配置，并且也可以通過備份系統(tǒng)的后臺(tái)模塊智能分析一批UDB實(shí)例的備份策略并記錄。
而B表的存在，使得每一個(gè)備份的情況都能夠進(jìn)行精確跟蹤。備份系統(tǒng)后臺(tái)可以定期分析B表的記錄，進(jìn)行后續(xù)的處理，比如給用戶告警。
幾個(gè)常見的備份恢復(fù)流程，都可以通過整套后臺(tái)系統(tǒng)和核心元數(shù)據(jù)的緊密配合來(lái)完成：
◎定時(shí)備份和手工備份：Access模塊接收到請(qǐng)求后，通過讀取表A的備份策略，將請(qǐng)求轉(zhuǎn)發(fā)到備份DB所在的物理機(jī)去執(zhí)行，備份完成后通過負(fù)載均衡算法上傳遠(yuǎn)端的NFS或是備份機(jī)集群
◎備份失敗檢測(cè)：Access模塊讀取表B的備份詳細(xì)信息和備份失敗原因，將告警發(fā)出，并且經(jīng)過分析之后，可以動(dòng)態(tài)修改A表該RDS的備份配置。保證RDS的備份成功率
◎下載備份：Access模塊接受到請(qǐng)求后讀取表B的信息，生成一個(gè)可下載的url
◎基于時(shí)間點(diǎn)的恢復(fù)：Access模塊接收到請(qǐng)求后，通過讀取表A的記錄獲取該實(shí)例的配置信息，生成一個(gè)相同配置的可用資源，再將請(qǐng)求轉(zhuǎn)發(fā)到這個(gè)可用資源（即恢復(fù)DB所在的物理機(jī)），在該物理機(jī)上新建出實(shí)例。接著通過讀取表B的記錄獲取備份信息，讀取表A的信息解析所需時(shí)間段的binlog，將備份和binlog導(dǎo)入新實(shí)例即完成恢復(fù)
◎通過備份新建一個(gè)RDS實(shí)例：步驟同上，略去了獲取和導(dǎo)入binlog
◎通過備份新建一個(gè)備庫(kù)實(shí)例：步驟同上，略去了獲取和導(dǎo)入binlog，改為指定復(fù)制源
UCloud UDB回檔操作整個(gè)海量DB的備份系統(tǒng)，為了方便用戶自助式的備份恢復(fù)操作，還需要包含一個(gè)易用的用戶管理界面，使得用戶在涉及到備份和恢復(fù)相關(guān)的操作都盡可能快捷，用戶通過控制臺(tái)界面或者API即可輕松實(shí)現(xiàn)備份和恢復(fù)的所有流程。
以UCloud UDB point-in-time回檔為例，云數(shù)據(jù)庫(kù)秒級(jí)回檔只需要按照以下步驟點(diǎn)幾下即可實(shí)現(xiàn)數(shù)據(jù)恢復(fù)，假設(shè)定時(shí)備份是凌晨3點(diǎn)，9點(diǎn)鐘發(fā)現(xiàn)數(shù)據(jù)庫(kù)故障，需要回檔到8:50，操作流程如下：
1 選定實(shí)例，選擇數(shù)據(jù)庫(kù)回檔功能
2 填入恢復(fù)實(shí)例名稱和需要恢復(fù)到的時(shí)間點(diǎn)，點(diǎn)擊確定即可
3 回到列表界面，即可看到這個(gè)新申請(qǐng)的回檔實(shí)例，等初始化完成后回檔就成功了
4 人工確認(rèn)數(shù)據(jù)確實(shí)回檔到準(zhǔn)確時(shí)間點(diǎn)
可以發(fā)現(xiàn)，整個(gè)恢復(fù)過程中，用戶只需要做一些配置，后臺(tái)就會(huì)把剩余的工作全部完成。整個(gè)恢復(fù)的體驗(yàn)更加方便友好。
備份安全性保障
常規(guī)安全性策略
業(yè)界有句話：沒有校驗(yàn)的備份等于沒有備份。我對(duì)這句話也是理解深刻，曾經(jīng)碰到過多次典型的情況比如備份時(shí)沒有記錄相應(yīng)的binlog和pos點(diǎn)導(dǎo)致point in time恢復(fù)時(shí)不好找準(zhǔn)確的pos點(diǎn)，大大增加了恢復(fù)難度；
再比如mysqldump邏輯備份時(shí)沒有考慮到部分表采用utf8mb4字符集，導(dǎo)致恢復(fù)后的數(shù)據(jù)庫(kù)亂碼情況等。以UDB為例，大型備份系統(tǒng)主要從以下幾個(gè)方面確保備份安全性：
◎備份失敗監(jiān)控，一旦備份失敗就會(huì)發(fā)送告警信息
◎定期抽取歷史備份記錄進(jìn)行恢復(fù)測(cè)試
◎備份上傳前后的MD5校驗(yàn)
◎備份過程中的全局讀鎖檢測(cè)，卡住時(shí)間太長(zhǎng)則發(fā)生告警信息
◎備份周期選擇上確保兩次間隔的binlog未過期
◎備份數(shù)據(jù)冗余，本地存一份最新的備份，異地存多天的歷史備份
◎備份機(jī)集群空間檢測(cè)和負(fù)載均衡，確保空間富余
◎備份重傳和重試
其中，備份的有效性測(cè)試方法大概是這樣的：?jiǎn)讉€(gè)對(duì)應(yīng)版本的數(shù)據(jù)庫(kù)并行測(cè)試，通過備份詳細(xì)記錄表獲取備份后將其傳送到這幾個(gè)實(shí)例進(jìn)行恢復(fù)測(cè)試。
由于實(shí)例數(shù)量較大，不可能每天都做恢復(fù)測(cè)試，通過讀取上一次校驗(yàn)時(shí)間和校驗(yàn)結(jié)果計(jì)算測(cè)試優(yōu)先級(jí)。越久沒有做過驗(yàn)證的備份優(yōu)先級(jí)越高，最近校驗(yàn)結(jié)果為失敗的次數(shù)越多的實(shí)例，優(yōu)先級(jí)也越高。
備份過程的全局讀鎖檢測(cè)，是因?yàn)閭浞葸^程中為了記錄當(dāng)前的pos點(diǎn)信息，都會(huì)執(zhí)行一個(gè)flush tables with read lock的操作，但是如果當(dāng)時(shí)有長(zhǎng)SQL未執(zhí)行完就會(huì)導(dǎo)致全局鎖等待，從而阻塞后續(xù)的所有寫請(qǐng)求。
為了使備份不影響業(yè)務(wù)，在備份開始后定期會(huì)檢測(cè)全局鎖等待，檢測(cè)到以后kill長(zhǎng)連接或者kill當(dāng)前備份線程。
這些備份的常規(guī)檢測(cè)都會(huì)在備份系統(tǒng)后臺(tái)定期全自動(dòng)執(zhí)行，保證了備份的成功率。
除了上述的考慮，有些特殊情況下光有備份還不夠。假設(shè)一個(gè)單實(shí)例UDB宕機(jī)，由于硬件故障物理機(jī)無(wú)法啟動(dòng)，物理機(jī)恢復(fù)時(shí)間茫茫無(wú)知。
這種情況下由于無(wú)法獲取最實(shí)時(shí)的binlog，僅僅通過歷史備份只能恢復(fù)到備份時(shí)間點(diǎn)，而無(wú)法恢復(fù)到故障前的時(shí)間點(diǎn)。
所以僅從安全性角度考慮，必要的備庫(kù)都是不可忽略的存在。
UDB出于客戶配置靈活，經(jīng)濟(jì)成本的考慮，既支持只創(chuàng)建單實(shí)例RDS，也可以創(chuàng)建高可用RDS和跨機(jī)房的master-slave RDS，對(duì)于重要的業(yè)務(wù)，一般都建議至少配置有備庫(kù)。
智能宕機(jī)恢復(fù)方法選擇數(shù)據(jù)庫(kù)宕機(jī)有時(shí)也會(huì)造成數(shù)據(jù)損壞導(dǎo)致無(wú)法正常啟動(dòng)的情況，以MySQL innodb為例，一般這時(shí)需要做一次force recovery，但是這時(shí)的業(yè)務(wù)恢復(fù)時(shí)間評(píng)估也顯得尤為重要。
UDB可以智能選擇在這種情況下采用何種恢復(fù)方式，即：
◎基于重新初始化DB+備份+binlog的恢復(fù)
◎force recovery啟動(dòng)+重新mysqldump+mv損壞數(shù)據(jù)+重新導(dǎo)入
主要基于以下幾點(diǎn)考慮：
◎原數(shù)據(jù)量大小評(píng)估，數(shù)據(jù)量越大，重新mysqldump的時(shí)間會(huì)越長(zhǎng)，但同樣的歷史備份傳輸+解壓時(shí)間也會(huì)越長(zhǎng)，需要找到一個(gè)平衡點(diǎn)
◎備份時(shí)間點(diǎn)到故障時(shí)間點(diǎn)的寫入量評(píng)估，寫入量越大，使用歷史備份+binlog花的時(shí)間也會(huì)越長(zhǎng)
◎恢復(fù)過程中適當(dāng)提到當(dāng)前RDS的IOPS上限
總結(jié)有效的備份和恢復(fù)策略對(duì)于數(shù)據(jù)庫(kù)安全的重要性不言而喻，而海量數(shù)據(jù)庫(kù)的備份系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)卻不是那么簡(jiǎn)單的一件事，需要考慮的細(xì)節(jié)還有很多。
希望本文對(duì)于有意研發(fā)海量DB備份系統(tǒng)的童鞋有一些幫助。沒有意向自研的童鞋，不妨考慮將數(shù)據(jù)庫(kù)遷移上云，讓強(qiáng)大的云數(shù)據(jù)庫(kù)為您的數(shù)據(jù)保駕護(hù)航。
獲得更多關(guān)于UCloud UDB產(chǎn)品資訊， 請(qǐng)點(diǎn)擊“閱讀原文”進(jìn)入U(xiǎn)DB產(chǎn)品頁(yè)面訪問，或者掃描左側(cè)二維碼進(jìn)一步交流
以上就是關(guān)于pos機(jī)備份電池電量低,從爐石傳說數(shù)據(jù)庫(kù)故障看云數(shù)據(jù)備份策略的知識(shí)，后面我們會(huì)繼續(xù)為大家整理關(guān)于pos機(jī)備份電池電量低的知識(shí)，希望能夠幫助到大家！
