[[378848]]

對于MySQL數(shù)據(jù)恢復而言，其實很多時候都會有點兒不踏實，大多數(shù)情況下備份恢復體系的建設是一氣呵成的，建設完善之后保持原樣，就很少干預和測試了，而一旦需要恢復的時候，才發(fā)現(xiàn)這也不好，那也不完善，輕則花費重金恢復，重則是職業(yè)生涯的終點。

所以我們在數(shù)據(jù)恢復的時候，我們特意完善了一個功能，那就是隨機恢復，隨機恢復主要實現(xiàn)兩個功能：基于備份集恢復和基于時間點恢復?；趥浞菁謴拖鄬Ρ容^簡單，就是什么時候做的備份，一定要恢復出來，而基于時間點會復雜一些，比如數(shù)據(jù)庫可以恢復到10:00:00，是需要實現(xiàn)精確到秒級的恢復能力，我們在此更進一步，生成一個隨機時間，然后讓服務按照指定的時間點進行恢復，每天大約會跑10個左右的任務，都是隨機從服務組中抽取。

經(jīng)過一段時間的調整和驗收，從50%左右的成功率不斷調整，到了現(xiàn)在的93%左右的成功率，我的初步要求是兩個9，這個標準提了一段時間了，從實踐的結果來看，這個標準要達成付出的代價和心血是很多的，遠遠不是看上去的那么輕松。

對此我對隨機恢復設置了3個段位，可以作為參考。

第一層級：隨機抽樣+單機恢復

這一層級思路很簡單，隨機從服務組中選取一個實例，到指定的恢復機恢復，只要數(shù)據(jù)庫能夠正常啟動則標識成功，否則，如果因為參數(shù)兼容性，版本差異，空間瓶頸，插件問題等導致無法啟動，都會標記為失敗。

當然這種模式的缺點也很明顯，那就是隨機的模式，最尷尬的無非是同樣的實例被反復選中，或者全是大塊頭的實例，對恢復造成很大的壓力導致失敗，另外則是恢復機成為瓶頸，跨機房流量和空間限制，會導致單一的恢復機難以支撐更高的指標要求，這也是早期難以突破1個9的主要原因。

第二層級：隨機抽樣+多IDC節(jié)點負載均衡

這種思路可操作性很強，優(yōu)點會很明顯，原本的恢復任務可以隨機的分配在不同的IDC中，對于跨機房流量消耗是一種很大的改良，同時也可以大大提高隨機恢復的吞吐量，比如我們原本可以跑10個隨機恢復任務，那么如果我們加到15個任務也可以說是輕輕松松。

第三層級：隨機策略調度+多IDC負載均衡

這是我認為目前改進空間很大，能夠迭代進入2個9的關鍵階段?？梢詮娜缦碌姆矫婵紤]：

1)恢復服務器實現(xiàn)多版本插件式部署，對于恢復服務器而言，不需要默認數(shù)據(jù)庫版本，所有差異化版本都是插件式目錄，可以快速構建恢復服務器，提高恢復擴展能力

2)根據(jù)恢復服務器的存儲和配置進行定制化延遲啟動，比如有的服務器CPU配置好一些，啟動數(shù)據(jù)庫快一些，有些數(shù)據(jù)庫啟動要略慢一些，可以通過配置化實現(xiàn)延遲啟動的問題，避免數(shù)據(jù)庫啟動中的一些尷尬問題

3)大容量實例在指定服務器中調度恢復，節(jié)省資源成本，比如有一個實例容量是800G,那么恢復機需要在900G左右，那么不是所有恢復服務器都需要900G,通常來說，這是極個別的現(xiàn)象，比如通用配置500G就足夠。

4)大容量的實例盡量減少調度頻率，如果一個實例的容量較大，恢復成本較高，那么我們可以有效恢復的基礎上調整恢復優(yōu)先級

5)未恢復的實例需要優(yōu)先調度，如果有1000個實例，如果經(jīng)過了很長時間，恢復的覆蓋范圍始終覆蓋不了大多數(shù)實例，其實隨機恢復的設計是有問題的。需要照顧到那些沒有被調度到的實例

6)實現(xiàn)彈性調度，比如對于容量小的實例，恢復效率會快很多，那么我們勢必就可以增加這類實例的恢復數(shù)量，而如果選中的實例容量較大，則可以在時長，數(shù)量方面做一些調控。

第4層級：根據(jù)統(tǒng)計學模型假設檢驗

在第3層級的基礎上，達到了兩個9的前提下，第4個層級會把恢復轉化為一個通用問題，對于如何衡量恢復能力在沒法實現(xiàn)全量數(shù)據(jù)集恢復的前提下，可以基于統(tǒng)計學的模型進行假設檢驗，最終的目的是通過一個有效樣本數(shù)據(jù)進行統(tǒng)計量的評估和分析，這個部分的內容理論深度其實沒那么復雜，是一種全新的思維邏輯去評估恢復質量。

本文轉載自微信公眾號「 楊建榮的學習筆記」，可以通過以下二維碼關注。轉載本文請聯(lián)系 楊建榮的學習筆記公眾號。