講師介紹

韓成亮,資深DBA,擁有7年DBA實戰經驗.目前從事MySQL相關運維及架構工作,擅長MySQL及Oracle設計和調優.

主題簡介：

1、MySQL之備份

2、MySQL之安全

3、MySQL之SQL規范

4、MySQL之系統規劃

一、MySQL之備份

之所以開頭就提這個,主要原因是最近的事故略多,刪主機、刪庫、刪表、刪字段還有勒索病毒等,太多的不可控因素了,從“刪XX到跑路”你缺少的只是一個“機會”.本來是你好、我好、大家好,但是萬一呢?所以要未雨綢繆,當然備份的意義不僅僅在于此.

1、可恢復性

首先談談備份的可恢復性,或者說是有效性.無論你的備份是在本地、異地、存儲、磁帶、云上、或者其它不知名處,如果不知道出啥問題丟失了,而且還必須要用這份文件恢復,不能有效的恢復,后果會很嚴重,所以在系統設計之初就需要規劃好.

一般而言我們同一份文件需要存放多個位置,三份是個不錯的選擇.常規的做法是本地一份,其它地方兩份,具體的可以根據實際條件酌情處理,通常一份的效驗很難有說服力,而且也并不可靠,一定要確保多份副本,從技術的角度而言,奇數是常用的仲裁配置,而三是最小的單位.

接下來就是需要經常驗證,我這邊說的是經常,日常不是很現實,如果資源足夠,那就完全可以實施了,這樣可以做到心里有底,避免真正在生產執行恢復的時候手忙腳亂,而且主要是可以通過預先準備的腳本或者命令,快速恢復.之所以一定要通過實踐去檢驗,因為通過實際的行為去排雷、排坑、排問題,盡可能地摸清楚將來可能會遇到的可能性問題.雖然可能性為零,不過平時多演練,這樣在真正需要的時候才能少掉坑里去.

如果說因為各方面的原因你沒法去驗證,只能通過系統自帶的驗證或者采取其他的諸如文件效驗的方式,這樣回到之前說的多副本情況,如果你擁有多分副本,起碼驗證起來還是比較簡單的,但是也并不是說多份副本就一定是有效的,還有時效性等問題.

2、時效性

這是建立在前面備份可恢復性基礎上,首先你的備份是可以支持恢復的,這個接下來需要關注備份的有效性,恢復的效率性.這里面會涉及到RPO、RTO,兩者是相互耦合的,RTO要求你越少的時間,RPO要求你恢復到最近時間點的數據,無論哪個方面,有效的解決方案都是更新的備份,更快的恢復效率,最好乃至于瞬間恢復到上一個事務,當前事務.不同的業務級別,需要不同的級別,當然災備另說.

時效性,說實話是屬于比較難界定的.那具體需要恢復到什么時間節點的數據呢?根據相應的RPO級別,需要指定相應的計劃,而且這其中還需要考慮RTO,如何縮短時間.如果說真的發生了需要從備份恢復的場景,首先需要確定你的數據庫擁有完整的備份,但是往往這個時候可能沒有最新的,要么就是最近的備份是不成功或者失敗,不要覺得我在危言聳聽.

事實往往比這個更復雜、更加嚴重,如果幸運的是,你不僅僅擁有多份可靠的而且是最新的備份,還有完美得是到宕機前一刻的增量或者日志,接下來就是跟時間賽跑,穩穩地減少宕機時間.

3、安全性

安全性放在最后,并不是說不重要,相反,主要高度依賴以上兩點,如果脫離了,就片面而言,沒有備份,那就是安全的,這是在沒有的情況下,不存在其它的情況.

然后就輪到有備份了,當你有了備份,你不僅僅需要保證備份的多副本,還要保證其安全性,這里面的安全性包括內部安全,外部安全.很多時候外部反而是安全的,一個有效的備份經歷加密、訪問控制,別人無論是獲取還是解密都需要花費大量時間的,而內部往往更容易出問題,千里之堤,毀于蟻穴.

提一下泄密,這個還是比較尷尬的,不論等級劃分,籠統來講,被權限以外的人接觸都算,那具體怎么界定,而且權限也是比較難劃分的,所以該有的預防措施必須要有.

安全無小事,相應的規定章程制定下來就需要嚴格的執行,剩下的這就需要看從業者的職業操守.

PS：如果需要了解備份恢復可以關注下社群文章《解鎖MySQL備份恢復的4種正確姿勢》,相信可以幫到你.

二、MySQL之安全

在生產中,安全是相當重要的,畢竟你的核心數據都在里面,MySQL因為其開源的流行性,大量個人、企業、政府單位都采用,但是很多在部署的時候采用都是默認的配置,這就導致了安全的相對欠缺,你需要針對你的安全有所加強.

總的來說,數據庫一般劃分為生產庫、壓測庫、準生產庫、測試庫、開發庫.下面部分主要說的是生產庫,但其它庫也適用.

1、mysql_secure_installation

這是數據庫基礎的安全設置腳本：

• 設置root密碼

• 移除匿名用戶

• 禁止遠程root登錄

• 移除test數據庫

以上是5.6版本,5.7有所加強但也僅此而已,看看你的環境是否存在上述問題,這個算是最基本的安全吧.

2、連接訪問安全

常見創建用戶時你需要指定你的IP訪問地址范圍或者固定IP,一般而言,只有特定唯一的幾個IP才會訪問,或者說你可以采用代理訪問的方式,減少應用直接訪問你的數據庫,而且現在很多中間件也都有白名單機制,原則上是把非法請求防止在數據庫以外的地方.

規范數據庫管理軟件,實現管理軟件的標準、統一化,還有嚴禁杜絕開啟外網訪問,如果客戶端在遠程,就根本不應該直接訪問數據庫,而應該使用中間件堡壘機或其它替代方案.

為了防止連入數據庫的應用程序存在后門,造成數據庫安全隱患,檢查所有連接數據庫程序的安全性.通過使用堡壘機或者其它監控登錄數據庫,禁止對數據庫的直接操作.

對已經連接的IP網段進行規范化、統一化的管理,定期進行權限復核操作,對系統所屬IP、用戶進行權限梳理工作.

對員工進行安全培訓,增強員工的系統安全觀念,做到細心操作,安全操作.確保訪問數據庫的主機為已知用戶或者主機,使用專門主機與數據庫進行連接.

對重要業務表的所有行為全部審計,審計同時所有包括即使是DBA的DDL操作行為.

最后是報表系統,利用審計的相關日志,出具系統化的審計報告.

3、權限安全

權限這塊無可厚非,在建立之初遵循最小權限原則,堅持最小權限原則,是數據庫安全的重要步驟.

以上說的是白話,下面說說正題.

很多時候我們不知道具體的最小權限是什么,你說一個賬號到底需要什么樣權限才合適,才不會影響業務?這個不是很好界定.我們需要知道在設置權限時的信息,要授予的權限級別、庫級別、表級別、列級別,或者其它超級權限、要授予的權限類型,增刪改查等.

從mysql.user表來看

用戶名、IP地址,是否需要連接數控制、SSL、過期時間等,不要怕麻煩,可能前期設置的時候比較繁瑣,但是一個好的基礎設置,才是安全地保障,做到需要什么給什么.

4、賬戶安全

用戶賬戶劃分原則：

• 超級管理員賬號

• 系統應用賬號(比如備份,監控,審計等)

• 應用業務賬號

• 業務人員賬號

• 開發人員賬號

• 測試人員賬號

• 其它專用賬號

主要是防止泄漏,非必要人員不需要知道賬號的名稱,同時需要制定相應的命名規則,還有就是合理使用自己的賬號密碼,保護好你的賬號密碼,對于絕無必要的用戶,先禁用,后期刪除,要做到無匿名賬戶和無廢棄賬戶.

5、目錄文件安全

提高本地安全性,主要是防止MySQL對本地文件的存取,會對系統構成威脅,還有Load DATA LOCAL INFILE,禁用該功能.

這個主要是防止誤刪除,非權限用戶禁止訪問目錄,還有就是數據文件禁止訪問,或者采用更改常用的目錄路徑,或者通過chroot,要保證該目錄不能讓未經授權的用戶訪問后把數據庫打包拷貝走了,所以要限制對該目錄的訪問.

6、密碼安全

• 密碼強度復雜性

盡量并且不要使用固定密碼,實行每個用戶單獨密碼,長度在16位以上 0-9a-zA-Z~!@#$%^&*()-+ 隨機組合.

• 密碼過期機制

根據公司的情況設定密碼過期時間,定期更改,同時不可使用重復密碼.

• 密碼保存機制

為了方便管理,可能會采用一個密碼表,要加強對于密碼表的維護更新,最重要的是保證不泄漏.

7、漏洞安全

常規的方式是安裝補丁,不過這個往往比較麻煩,主要是版本升級,還有就是防護策略.

8、被忽視的SSL

由于性能或者其它方面原因,很多生產環境并沒有使用,不過從5.7+開始,已經好很多了,有需要的加強安全防范其實可以嘗試下了.

https://dev.mysql.com/doc/refman/5.7/en/mysql-ssl-rsa-setup.html

9、防火墻安全

一般化數據庫前面都會有主備的墻,不過從成本上考慮,很多企業都是單個或者裸奔的,有自己的硬件防火墻最好,沒有的話也可以使用系統自帶的防火墻,然后在加上其它白名單和中間件白名單過濾輔助措施,也能防止一部分問題.

10、端口安全

默認端口是3306,這個最好修改下,為了方便記憶,你可以根據的IP地址來加密動態調整,不過如果生產網絡允許,也可以定期修改,最好不要影響研發進度.

11、記錄安全

刪除操作系統記錄的敏感數據,比如.mysql_history、.bash_history 等,及時清理,移除和禁用.mysql_history文件.

人是安全的主導,管理的對象要從兩個角度來看,從信息角度來說就是MySQL本身的安全,要防止數據的丟失和免遭破壞；從技術角度來說就是整個系統的安全,要防止系統的癱瘓和免遭破壞.

最后說句題外話,監控和審計,安全主要是防患于未然,沒有誰希望一天到晚接到各種警報,最好根據公司的實際情況訂個詳細的規章制度,不要覺得這個麻煩,有些你可能并不覺得有用,但是呢?我希望是沒有但是.

三、MySQL之SQL規范

不以規矩,不成方圓.

無可否認,很多時候由于項目的開發迭代過于頻繁,實時的需求反饋,可以及時調整產品的方向,不過由于各種大大小小的功能的耦合交錯,還有研發人員對數據庫的了解參差不齊,他們可能更加關注的是功能的實現,其次可能才是響應速度,這就導致了由于數據量小時看不出問題的SQL,一旦遇到大數據量,查詢性能或者說系統的響應速度會變慢,這是個值得關注的地方,為了防止出現這種情況,你需要做點什么.

1、使用什么

• 使用 InnoDB 存儲引擎,默認使用utf8mb4 字符集

• 使用自增主鍵,盡量每個表都有而且是非業務鍵值

• 使用合適的字段類型,比如 VARCHAR 代替 CHAR 等,最好確定好長度

• 使用盡可能小的 VARCHAR 字段

• 使用合適的 INTEGER、INT、SMALLINT、TINYINT、MEDIUMINT、 BIGINT 數據類型.

  https://dev.mysql.com/doc/refman/5.7/en/integer-types.html

• 使用 UNSIGNED 存儲非負數值,比如自增等

• 使用 INT UNSIGNED 存儲 IPV4 INET_ATON、INET_NTOA.

  更多 https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html

• 必須使用 DECIMAL 代替 FLOAT 和 DOUBLE 存儲精確浮點數,比如與貨幣、金融相關的數據,防止運算丟失精度問題

• 使用注釋,所有表都需要添加注釋；除自增主鍵外的其他字段都需要增加注釋

• 使用默認值,所有字段都必須擁有默認值,不在表中存儲 NULL

• 使用 PREPARED STATEMENT,防止SQL注入

• 使用合理的 LIMIT 分頁方式以提高分頁效率

• 使用 EXISTS 適用于子查詢不返回實際數據,而表較大的情況,如果子查詢表較少可以考慮用in

• 使用 IN 代替 OR,同時 SQL 語句中IN包含的值不應過多,應少于1000個,否則使用轉為字符串LIKE

• 使用 UNION ALL代替 UNION,減少不必要的去重消耗

• 使用 COUNT(1) 統計行數,如果使用字段的話可能存在空值或NULL不準的情況

• 使用 INDEX,所有 WHERE 條件必須有索引,特別是 DELETE / UPDATE

• 使用 EXPLAIN EXTENDED 判斷SQL語句是否合理使用索引

• 使用 SHOW PROFILES 跟蹤資源使用

• 使用事務,增刪改必須有,程序應有捕獲SQL異常的處理機制

• 使用從庫,不是必要的查詢一律使用從庫查詢,減輕主庫壓力

2、減少什么

• 減少不必要的固化查詢,合理使用 Memcached、Redis、MongoDB等

• 減少不需要的空連接,及時關閉

• 減少不必要的連接,盡量采用批量SQL語句

• 減少不必要的大事務,盡量做拆分

• 減少查詢的數據量,大量查詢分批次

• 減少游標和臨時表的使用,如果有的話

3、避免什么

• 避免使用TEXT、BLOB類型等

• 避免向客戶端返回大數據量,若數據量過大,應該考慮相應需求是否合理

• 避免使用子查詢 IN ,必要時使用JOIN.

• 避免出現NOW()、RAND()、SYSDATE()、CURRENT_USER()等不確定結果的函數

• 避免在索引列上使用IS NULL和IS NOT NULL

• 避免同一個表上索引過多,重復索引,太多的索引可能提高了查詢效率,但是也增加了增刪改的開銷

4、禁止什么

• 禁止在數據庫中存儲圖片、文件等大數據

• 禁止使用order by rand(),類似的有很多替代方案

• 禁止使用SELECT *,根據需要獲取相對應需要的字段

• 禁止使用預留字段,無論從流程和規范上都說不過去

• 禁止在MySQL中進行數學運算和函數運算

• 禁止隱式轉換,數值類型禁止加引號,字符串類型必須加引號

• 禁止使用 INSERT INTO TABLE(),需要指定相應的字段,最好是順序的

• 禁止使用前置百分號,例如：WHERE A LIKE ‘%B’

• 禁止使用 NOT 查詢,例如 NOT IN、!=、NOT LIKE

• 禁止單條SQL語句同時更新多個表

• 禁止使用存儲過程、觸發器、視圖、自定義函數等

• 禁止在從庫上執行負責統計類查詢,使用專用從庫

• 禁止在數據庫中存儲明文密碼

5、注意什么

• 合并對于單表多次的操作

• 表結構變更必須通知DBA審核參與

• 重要項目的數據庫方案選型和設計必須提前通知DBA參與

• 禁止在線上做數據庫壓力測試

• 禁止從測試、開發環境直連線上數據庫

• 禁止有超級權限的應用程序賬號存在

• 禁止有DDL、DCL權限的應用程序賬號存在

• 批量導入、導出數據必須通過DBA審核,并在執行過程中觀察服務

• 批量更新數據,如UPDATE、DELETE操作,必須DBA進行審核,并在執行過程中觀察服務

• 產品出現非數據庫導致的故障時,如被攻擊,必須及時通DBA,便于維護服務穩定

• 業務部門程序出現BUG等影響數據庫服務的問題,必須及時通知DBA,便于維護服務穩定

• 業務部門推廣活動或上線新功能,必須提前通知DBA進行服務和訪問量評估,并留出必要時間以便DBA完成擴容

• 出現業務部門人為誤操作導致數據丟失,需要恢復數據的,必須第一時間通知DBA,并提供準確時間點、 誤操作語句等重要線索

• 提交線上建表改表需求,必須詳細注明涉及到的所有SQL語句(包括INSERT、DELETE、UPDATE),便于DBA進?行審核和優化

以上相對比較常規,一個完善合理的規范當然還需要一個比較長的過程.

四、MySQL之系統規劃

1、環境規劃

MySQL作為流行的開源數據庫擁有多個重要分支,每個分支都有各自的優缺點,這里不做過多評價,總的來說,MySQL仍然是一款非常出色的產品,是一個非常適合大多數場景下使用的數據庫,無論是從可用性、可擴展性、性能和管理各方面都是不錯的選擇.

當然說為了追求某些方面的新的功能性需求,或者MySQL版本覺得太臃腫,你也可以嘗試其他版本,主要是符合你的業務場景才是最合適的.

根據研發的階段來劃分主要分為開發階段、測試階段、準生產階段、壓測階段、上線階段.

• 開發階段-開發環境

數據庫和系統的版本可能都比較新,這里面有一部分是嘗鮮的概念在里面,同時,也為了以后的版本更新提供了一定的基礎,其次是研發人員對于數據庫和操作系統的權限是比較大的,基本上會all in,主要保證開發的進度.

• 測試階段-測試環境

這個環境的版本可能也是比較新的,不過已經很貼近生產了,然后是對于權限的話,由于主要是測試階段,研發人員和測試人員的權限基本上限定到庫表的DML權限,很難執行其它特別是DDL操作了,當然還是以保證開發和測試為主.

• 準生產階段-準生產環境

原則上這個環境跟生產環境基本上1：1,版本跟生產是一樣的,其次配置比生產會低很多,權限的話,已經不允許DDL語句了,并且DML也會嚴格控制.

• 壓測階段–壓測環境

一般化而言,很多公司會把準這個壓測環境放到準生產上面,對此,我不反對不建議,完全看你的想法和公司的規劃,壓測環境跟生產環境保證100%完全一致性,因為為了追求那個極致,同時全面禁止的DDL,只讀環境.

PS：很多時候,你的準生產可能就是壓測環境,這邊就不做過多說明了,主要還是看你的規劃.

• 上線階段–線上環境

這個就不說了,完全禁止的DML、DDL操作,任何操作必須有記錄,比如審計、工單等等.

2、容量規劃

容量規劃主要是如何有效評估需求,如果說沒有統一綜合的管理機制,各種項目的資源申請各自為政,沒有考慮到綜合實際使用的資源情況,會造成嚴重的分配問題,或者說資源不足,有可能部分項目的提前預支超過實際情況的資源,其它項目完全沒有資源,或者項目資源是有時間期限的,過了期限就需要即使的回收利用.

對于數據庫本身容量規劃更加重要,畢竟你的數據都在里面,首先項目初始階段可能會預估下使用量,然后還需要定期的實際評估,根據資源的使用情況及時調整,綜合規劃各個項目的資源配置.

MySQL的容量規劃主要是庫表的大小,這個主要是看業務量,很多時候業務部門會說我的計劃目標是1kw用戶量,那么可能很難有一個估計的大小,因為你的庫表一直是在變化的,自然而言,比較困難評估一個大概的容量,而且如果數據量太大的情況下,從數據的訪問響應速度就需要考慮分庫分表了,這個主要還是看的業務場景和需要的響應速度.

3、文件規劃

MySQL數據文件目錄還是比較簡單的,可以分成數據文件目錄、日志文件目錄、參數文件目錄、其它文件目錄等.

• 數據文件目錄

數據文件主要按照庫表單位劃分的,由于引擎的不同可能分成結構定義文件、數據文件、索引文件.

• 日志文件目錄

這里面包括了啟動日志、報錯日志、查詢日志、慢查詢日志、binlog日志、binlog索引文件、relay_log中繼日志、relay_log中繼日志索引文件等.

• 參數文件目錄

包括pid、sock、cnf 文件等.

• 其他文件目錄

包括redo、undo、ibdata1、ibtmp1文件等.

歸檔,這邊說的歸檔規劃是定期把以上各類文件備份歸檔,數據文件自不必說,其它文件也是需要定期歸檔的,歸檔的方法有很多,你可以把相應的文件根據不同的規律存放在結構化或者非結構化的地方.

4、審計規劃

數據庫審計能夠實時記錄網絡上的數據庫活動,對數據庫操作進行細粒度審計的合規性管理,對數據庫遭受到的風險行為進行告警,對攻擊行為進行阻斷.

它通過對用戶訪問數據庫行為的記錄、分析和匯報,用來幫助用戶事后生成合規報告、事故追根溯源,同時加強內外部數據庫網絡行為記錄,提高數據安全.

審計對數據庫記錄和行為進行獨立的審查和估計,其主要作用和目的包括以下幾個方面：

• 對可能存在的潛在攻擊者起到威懾和警示作用,核心是風險評估.

• 測試系統的控制情況,及時進行調整,保證與安全策略和操作規程協調一致.

• 對已出現的破壞事件,做出評估并提供有效的災難恢復和追究責任的依據.

• 對系統控制、安全策略與規程中的變更進行評價和反饋,以便修訂決策和部署.

• 協助系統管理員及時發現網絡系統入侵或潛在的系統漏洞及隱患.

有個不知道算奇怪還是正常的事情,不知道多少人給生產恢復過數據,這里面不談因由,只有做過的人才知道這其中的坑有多少,所以也就需要大家對于各種恢復手段都有所了解,乃至于熟練掌握.

雖然防患未然還是比較困難,畢竟各種情況都會發生,但至少可以未雨綢繆,從安全上講,有了審計就可以大大減少這類事情的發生.

對于數據庫而言,無論是硬件設備還是軟件審計都會加大數據庫的壓力,從性能的損耗上講,事后審計是比較折中的策略,這邊先講下軟件部分的,無論是MySQL官方還是MariaDB或者Percona還是其它的都有一套自己的審計產品.

下面列下常用的幾種：

• MariaDB Audit Plugin(https://mariadb.com/kb/en/mariadb/about-the-mariadb-audit-plugin/),

• Percona(https://www.percona.com/doc/percona-server/5.6/management/audit_log_plugin.html),

• MySQL(https://dev.mysql.com/doc/refman/5.7/en/audit-log.html),

  mcafee(https://github.com/mcafee/mysql-audit)

主要用哪個還得看你適合哪個,如果你有足夠的資源可以考慮采用硬件的模式,盡量選擇專門審計設備的設備,然后根據定期的報表檢查你的相關配置.

前面列出的幾個感興趣的小伙伴可以具體測試下,當然如果你已經在使用了,那我們可以私下交流.

5、備份恢復規劃

備份和恢復是兩個相互關聯的,至于備份恢復的種種前面已經有說過了,關于備份恢復也有一系列的軟硬件,這邊主要說下規劃.

你首選要根據自己的實際情況做需求分析,你需要有當前使用數據庫的類型、版本信息、配置信息、數據量總大小、每日新增大小、備份方式(物理備份/邏輯備份)、業務高峰期,當然還有數據庫的主機的系統情況等信息.

備份策略,根據不同的業務還有其它需要確定,常用的是全量、增量、差異備份三種,實際情況下很多都是三種策略的結合使用.

備份大小,這個取決于你采用的備份方式,會有一個大致的增長值,這個可能需要跟業務那邊的規劃做詳細的統計,給出一個大概的范圍.

備份保留時間,這個跟備份的大小、備份介質的大小、性價比有關系.

如果你的介質空間太小,自然而然也就不能保留太長時間,這個時候,通常會根據業務的核心程度來劃分,應確定重要業務備份的保存期以及其它需要永久保存的備份,總的來說,保留半年之類的有效數據是基本的要求.

備份介質大小,根據你的保留時間合理地規劃你的備份介質大小.

備份計劃,這個跟恢復策略有關系,基本上是你需要一個專門備份的數據庫,這個主要是為了減少對主庫的影響,對此大部分是數據庫都支持該方案,當然主庫執行備份也不是不可以,只要合理使用.

根據業務繁忙的情況,在合理的時間和空間下能全備的盡量全備,雖然全量可能會增加數據的重復性和空間的使用,你可以適當加上增量或者差異備份.

太大的庫可能全備時間太長,優化過后還是不能接受,可以選擇一個相對不繁忙的時間做全量備份,然后加上增量或者差異備份,當然這個全量的頻率還是需要根據你的業務來結合.總不能說,我需要恢復昨天的數據,你告訴我只有上上上個月的全備加上增量或者差異,這個恢復的時間一般會比較長,這個肯定不能滿足的需求,所以備份計劃要完全貼合你的業務需求,以及需要詳細指定最大容忍的時間性要求.

備份執行過程應有詳細的規劃和記錄,包括備份重要等級、備份主體、備份時間、備份策略、備份路徑、記錄介質(類型)等.

同時備份文件加密權限控制也是不可或缺的,所有操作需要保留相應記錄,方便審計跟蹤,安全需要時刻關注.

恢復規劃,這個不能說是規劃,我覺得這個應該更像一個日常的計劃任務,如果你有充足的資源,特別的恢復服務器組,我希望你在每天完成備份并且上傳統一的備份介質后,每天都可以把所有的系統都恢復一次,不要覺得太麻煩,有時候這些麻煩會幫你很多,當你把所有的一切做成定時任務之后,你會發現,生活太美好.

實際的情況往往比這個更加復雜,我們把容災劃分成很多的等級,計算機軟件故障、人為原因、計劃性停機,然后從等級上是時間上有幾個九,同時還有災備的環境一些措施,確保可以在規定的時間內完成有效性恢復.

但是,當災難發生的時候,很多東西都會很巧合地并發發生,會很亂,假使災備環境也不是正常的或者壓根就沒有所謂的災備環境,那個時候你依賴的可能也僅僅是備份的一個有效恢復,那個時候,壓力會稍微有點大,如果你對恢復情況不是很了解,或者不是很熟練,我們也只能就這么看著能恢復多少,心里沒有底,這個時候才會覺得恢復測試真的非常重要.

平時我們關注的大都在日常的備份上,并不會實際去驗證,不過其實日常恢復演練更加重要,即使不能做到所有系統的恢復計劃,起碼保證核心系統的備份的有效性,同時制定恢復測試計劃.

總結

總之,對于數據庫而言,首先要求我們擁有一個完整的備份,有了備份你才能做很多事,同時也會省了很多事.其次是安全,無論是數據備份的安全還是數據本身或者研發使用中的安全,都值得關注.然后是數據庫本身的使用,合情合理的使用.最后對于你所維護的數據庫你需要擁有詳細的規劃,無論是管理角度還是使用角度都需要.

最后給大家提幾點建議：

1. 未雨綢繆,不要停留在制度上,而是實際做出來.

2. 亡羊補牢,舉一反三,切記,不能好了傷疤忘了疼.

3. 完備的架構設計及備份,恢復策略及備份驗證策略.

4. 定期思考,并實戰模擬以上策略演練.

5. 實踐是檢驗真理的唯一標準.

一家之言,姑妄聽之,如有疏漏錯誤的,歡迎大家一起探討.

O&A

Q1：請問跨機房同步是如何做的?中間件?

A1：目前我們跨機房同步采用的專用光纖,其實這個主要看你們業務的可接受的響應時間.

Q2：準生產環境和生產環境如何同步呢?定期覆蓋?敏感數據如何確保安全?因為我是新手,所以問題可能比較初級.

A2：準生產和生產的同步,主要看你們的測試要求,還有一些合作方的需求,這里面肯定包涵了一部分生產的數據,其它可能是一些隨機數據,至于敏感信息,看你們對于信息的要求常見的四要素：姓名、身份證、手機號、銀行卡、地址之類的信息,這些在不影響業務流程的情況下,會進行部分字段部分加密或者替換隨機數據.

Q3：請問有沒有一些好的數據庫層的高可用架構方案,可以保證數據丟失的概率最小呢?

A3：您可以先熟悉下常用的MySQL高可用架構MS、MMM、MHA、PXC、MGR,籠統的說都可以滿足您的需求,具體的還得看業務.

End.

來源：公眾號“DBAplus社群”

運行人員：中國統計網小編(微信號：itongjilove)

微博ID：中國統計網

中國統計網,是國內最早的大數據學習網站,公眾號：中國統計網

http://www.itongji.cn