[[197830]]

一、MySQL之備份

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

1、可恢復(fù)性

首先談?wù)剛浞莸目苫謴?fù)性，或者說是有效性。無論你的備份是在本地、異地、存儲(chǔ)、磁帶、云上、或者其它不知名處，如果不知道出啥問題丟失了，而且還必須要用這份文件恢復(fù)，不能有效的恢復(fù)，后果會(huì)很嚴(yán)重，所以在系統(tǒng)設(shè)計(jì)之初就需要規(guī)劃好。

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

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

如果說因?yàn)楦鞣矫娴脑蚰銢]法去驗(yàn)證，只能通過系統(tǒng)自帶的驗(yàn)證或者采取其他的諸如文件效驗(yàn)的方式，這樣回到之前說的多副本情況，如果你擁有多分副本，起碼驗(yàn)證起來還是比較簡單的，但是也并不是說多份副本就一定是有效的，還有時(shí)效性等問題。

2、時(shí)效性

這是建立在前面?zhèn)浞菘苫謴?fù)性基礎(chǔ)上，首先你的備份是可以支持恢復(fù)的，這個(gè)接下來需要關(guān)注備份的有效性，恢復(fù)的效率性。這里面會(huì)涉及到RPO、RTO，兩者是相互耦合的，RTO要求你越少的時(shí)間，RPO要求你恢復(fù)到最近時(shí)間點(diǎn)的數(shù)據(jù)，無論哪個(gè)方面，有效的解決方案都是更新的備份，更快的恢復(fù)效率，最好乃至于瞬間恢復(fù)到上一個(gè)事務(wù)，當(dāng)前事務(wù)。不同的業(yè)務(wù)級(jí)別，需要不同的級(jí)別，當(dāng)然災(zāi)備另說。

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

事實(shí)往往比這個(gè)更復(fù)雜、更加嚴(yán)重，如果幸運(yùn)的是，你不僅僅擁有多份可靠的而且是最新的備份，還有完美得是到宕機(jī)前一刻的增量或者日志，接下來就是跟時(shí)間賽跑，穩(wěn)穩(wěn)地減少宕機(jī)時(shí)間。

3、安全性

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

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

提一下泄密，這個(gè)還是比較尷尬的，不論等級(jí)劃分，籠統(tǒng)來講，被權(quán)限以外的人接觸都算，那具體怎么界定，而且權(quán)限也是比較難劃分的，所以該有的預(yù)防措施必須要有。

安全無小事，相應(yīng)的規(guī)定章程制定下來就需要嚴(yán)格的執(zhí)行，剩下的這就需要看從業(yè)者的職業(yè)操守。

PS：如果需要了解備份恢復(fù)可以關(guān)注下社群文章《解鎖MySQL備份恢復(fù)的4種正確姿勢》，相信可以幫到你。

二、MySQL之安全

在生產(chǎn)中，安全是相當(dāng)重要的，畢竟你的核心數(shù)據(jù)都在里面，MySQL因?yàn)槠溟_源的流行性，大量個(gè)人、企業(yè)、政府單位都采用，但是很多在部署的時(shí)候采用都是默認(rèn)的配置，這就導(dǎo)致了安全的相對(duì)欠缺，你需要針對(duì)你的安全有所加強(qiáng)。

總的來說，數(shù)據(jù)庫一般劃分為生產(chǎn)庫、壓測庫、準(zhǔn)生產(chǎn)庫、測試庫、開發(fā)庫。下面部分主要說的是生產(chǎn)庫，但其它庫也適用。

1、mysql_secure_installation

這是數(shù)據(jù)庫基礎(chǔ)的安全設(shè)置腳本：

• 設(shè)置root密碼
• 移除匿名用戶
• 禁止遠(yuǎn)程root登錄
• 移除test數(shù)據(jù)庫

以上是5.6版本，5.7有所加強(qiáng)但也僅此而已，看看你的環(huán)境是否存在上述問題，這個(gè)算是最基本的安全吧。

2、連接訪問安全

常見創(chuàng)建用戶時(shí)你需要指定你的IP訪問地址范圍或者固定IP，一般而言，只有特定唯一的幾個(gè)IP才會(huì)訪問，或者說你可以采用代理訪問的方式，減少應(yīng)用直接訪問你的數(shù)據(jù)庫，而且現(xiàn)在很多中間件也都有白名單機(jī)制，原則上是把非法請(qǐng)求防止在數(shù)據(jù)庫以外的地方。

規(guī)范數(shù)據(jù)庫管理軟件，實(shí)現(xiàn)管理軟件的標(biāo)準(zhǔn)、統(tǒng)一化，還有嚴(yán)禁杜絕開啟外網(wǎng)訪問，如果客戶端在遠(yuǎn)程，就根本不應(yīng)該直接訪問數(shù)據(jù)庫，而應(yīng)該使用中間件堡壘機(jī)或其它替代方案。

為了防止連入數(shù)據(jù)庫的應(yīng)用程序存在后門，造成數(shù)據(jù)庫安全隱患，檢查所有連接數(shù)據(jù)庫程序的安全性。通過使用堡壘機(jī)或者其它監(jiān)控登錄數(shù)據(jù)庫，禁止對(duì)數(shù)據(jù)庫的直接操作。

對(duì)已經(jīng)連接的IP網(wǎng)段進(jìn)行規(guī)范化、統(tǒng)一化的管理，定期進(jìn)行權(quán)限復(fù)核操作，對(duì)系統(tǒng)所屬IP、用戶進(jìn)行權(quán)限梳理工作。

對(duì)員工進(jìn)行安全培訓(xùn)，增強(qiáng)員工的系統(tǒng)安全觀念，做到細(xì)心操作，安全操作。確保訪問數(shù)據(jù)庫的主機(jī)為已知用戶或者主機(jī)，使用專門主機(jī)與數(shù)據(jù)庫進(jìn)行連接。

對(duì)重要業(yè)務(wù)表的所有行為全部審計(jì)，審計(jì)同時(shí)所有包括即使是DBA的DDL操作行為。

最后是報(bào)表系統(tǒng)，利用審計(jì)的相關(guān)日志，出具系統(tǒng)化的審計(jì)報(bào)告。

3、權(quán)限安全

權(quán)限這塊無可厚非，在建立之初遵循最小權(quán)限原則，堅(jiān)持最小權(quán)限原則，是數(shù)據(jù)庫安全的重要步驟。

以上說的是白話，下面說說正題。

很多時(shí)候我們不知道具體的最小權(quán)限是什么，你說一個(gè)賬號(hào)到底需要什么樣權(quán)限才合適，才不會(huì)影響業(yè)務(wù)?這個(gè)不是很好界定。我們需要知道在設(shè)置權(quán)限時(shí)的信息，要授予的權(quán)限級(jí)別、庫級(jí)別、表級(jí)別、列級(jí)別，或者其它超級(jí)權(quán)限、要授予的權(quán)限類型，增刪改查等。

從mysql.user表來看

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

4、賬戶安全

用戶賬戶劃分原則：

• 超級(jí)管理員賬號(hào)
• 系統(tǒng)應(yīng)用賬號(hào)(比如備份，監(jiān)控，審計(jì)等)
• 應(yīng)用業(yè)務(wù)賬號(hào)
• 業(yè)務(wù)人員賬號(hào)
• 開發(fā)人員賬號(hào)
• 測試人員賬號(hào)
• 其它專用賬號(hào)

主要是防止泄漏，非必要人員不需要知道賬號(hào)的名稱，同時(shí)需要制定相應(yīng)的命名規(guī)則，還有就是合理使用自己的賬號(hào)密碼，保護(hù)好你的賬號(hào)密碼，對(duì)于絕無必要的用戶，先禁用，后期刪除，要做到無匿名賬戶和無廢棄賬戶。

5、目錄文件安全

提高本地安全性，主要是防止MySQL對(duì)本地文件的存取，會(huì)對(duì)系統(tǒng)構(gòu)成威脅，還有Load DATA LOCAL INFILE，禁用該功能。

這個(gè)主要是防止誤刪除，非權(quán)限用戶禁止訪問目錄，還有就是數(shù)據(jù)文件禁止訪問，或者采用更改常用的目錄路徑，或者通過chroot，要保證該目錄不能讓未經(jīng)授權(quán)的用戶訪問后把數(shù)據(jù)庫打包拷貝走了，所以要限制對(duì)該目錄的訪問。

6、密碼安全

密碼強(qiáng)度復(fù)雜性

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

密碼過期機(jī)制

根據(jù)公司的情況設(shè)定密碼過期時(shí)間，定期更改，同時(shí)不可使用重復(fù)密碼。

密碼保存機(jī)制

為了方便管理，可能會(huì)采用一個(gè)密碼表，要加強(qiáng)對(duì)于密碼表的維護(hù)更新，最重要的是保證不泄漏。

7、漏洞安全

常規(guī)的方式是安裝補(bǔ)丁，不過這個(gè)往往比較麻煩，主要是版本升級(jí)，還有就是防護(hù)策略。

8、被忽視的SSL

由于性能或者其它方面原因，很多生產(chǎn)環(huán)境并沒有使用，不過從5.7+開始，已經(jīng)好很多了，有需要的加強(qiáng)安全防范其實(shí)可以嘗試下了。

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

9、防火墻安全

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

10、端口安全

默認(rèn)端口是3306，這個(gè)最好修改下，為了方便記憶，你可以根據(jù)的IP地址來加密動(dòng)態(tài)調(diào)整，不過如果生產(chǎn)網(wǎng)絡(luò)允許，也可以定期修改，最好不要影響研發(fā)進(jìn)度。

11、記錄安全

刪除操作系統(tǒng)記錄的敏感數(shù)據(jù)，比如.mysql_history、.bash_history 等，及時(shí)清理，移除和禁用.mysql_history文件。

人是安全的主導(dǎo)，管理的對(duì)象要從兩個(gè)角度來看，從信息角度來說就是MySQL本身的安全，要防止數(shù)據(jù)的丟失和免遭破壞;從技術(shù)角度來說就是整個(gè)系統(tǒng)的安全，要防止系統(tǒng)的癱瘓和免遭破壞。

最后說句題外話，監(jiān)控和審計(jì)，安全主要是防患于未然，沒有誰希望一天到晚接到各種警報(bào)，最好根據(jù)公司的實(shí)際情況訂個(gè)詳細(xì)的規(guī)章制度，不要覺得這個(gè)麻煩，有些你可能并不覺得有用，但是呢?我希望是沒有但是。

三、MySQL之SQL規(guī)范

不以規(guī)矩，不成方圓。

無可否認(rèn)，很多時(shí)候由于項(xiàng)目的開發(fā)迭代過于頻繁，實(shí)時(shí)的需求反饋，可以及時(shí)調(diào)整產(chǎn)品的方向，不過由于各種大大小小的功能的耦合交錯(cuò)，還有研發(fā)人員對(duì)數(shù)據(jù)庫的了解參差不齊，他們可能更加關(guān)注的是功能的實(shí)現(xiàn)，其次可能才是響應(yīng)速度，這就導(dǎo)致了由于數(shù)據(jù)量小時(shí)看不出問題的SQL，一旦遇到大數(shù)據(jù)量，查詢性能或者說系統(tǒng)的響應(yīng)速度會(huì)變慢，這是個(gè)值得關(guān)注的地方，為了防止出現(xiàn)這種情況，你需要做點(diǎn)什么。

1、使用什么

• 使用 InnoDB 存儲(chǔ)引擎，默認(rèn)使用utf8mb4 字符集
• 使用自增主鍵，盡量每個(gè)表都有而且是非業(yè)務(wù)鍵值
• 使用合適的字段類型，比如 VARCHAR 代替 CHAR 等，最好確定好長度
• 使用盡可能小的 VARCHAR 字段
• 使用合適的 INTEGER、INT、SMALLINT、TINYINT、MEDIUMINT、 BIGINT 數(shù)據(jù)類型。https://dev.mysql.com/doc/refman/5.7/en/integer-types.html
• 使用 UNSIGNED 存儲(chǔ)非負(fù)數(shù)值，比如自增等
• 使用 INT UNSIGNED 存儲(chǔ) IPV4 INET_ATON、INET_NTOA。更多 https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html
• 必須使用 DECIMAL 代替 FLOAT 和 DOUBLE 存儲(chǔ)精確浮點(diǎn)數(shù)，比如與貨幣、金融相關(guān)的數(shù)據(jù)，防止運(yùn)算丟失精度問題
• 使用注釋，所有表都需要添加注釋;除自增主鍵外的其他字段都需要增加注釋
• 使用默認(rèn)值，所有字段都必須擁有默認(rèn)值，不在表中存儲(chǔ) NULL
• 使用 PREPARED STATEMENT，防止SQL注入
• 使用合理的 LIMIT 分頁方式以提高分頁效率
• 使用 EXISTS 適用于子查詢不返回實(shí)際數(shù)據(jù)，而表較大的情況，如果子查詢表較少可以考慮用in
• 使用 IN 代替 OR，同時(shí) SQL 語句中IN包含的值不應(yīng)過多，應(yīng)少于1000個(gè)，否則使用轉(zhuǎn)為字符串LIKE
• 使用 UNION ALL代替 UNION，減少不必要的去重消耗
• 使用 COUNT(1) 統(tǒng)計(jì)行數(shù)，如果使用字段的話可能存在空值或NULL不準(zhǔn)的情況
• 使用 INDEX，所有 WHERE 條件必須有索引，特別是 DELETE / UPDATE
• 使用 EXPLAIN EXTENDED 判斷SQL語句是否合理使用索引
• 使用 SHOW PROFILES 跟蹤資源使用
• 使用事務(wù)，增刪改必須有，程序應(yīng)有捕獲SQL異常的處理機(jī)制
• 使用從庫，不是必要的查詢一律使用從庫查詢，減輕主庫壓力

2、減少什么

• 減少不必要的固化查詢，合理使用 Memcached、Redis、MongoDB等
• 減少不需要的空連接，及時(shí)關(guān)閉
• 減少不必要的連接，盡量采用批量SQL語句
• 減少不必要的大事務(wù)，盡量做拆分
• 減少查詢的數(shù)據(jù)量，大量查詢分批次
• 減少游標(biāo)和臨時(shí)表的使用，如果有的話

3、避免什么

• 避免使用TEXT、BLOB類型等
• 避免向客戶端返回大數(shù)據(jù)量，若數(shù)據(jù)量過大，應(yīng)該考慮相應(yīng)需求是否合理
• 避免使用子查詢 IN ，必要時(shí)使用JOIN。
• 避免出現(xiàn)NOW()、RAND()、SYSDATE()、CURRENT_USER()等不確定結(jié)果的函數(shù)
• 避免在索引列上使用IS NULL和IS NOT NULL
• 避免同一個(gè)表上索引過多，重復(fù)索引，太多的索引可能提高了查詢效率，但是也增加了增刪改的開銷

4、禁止什么

• 禁止在數(shù)據(jù)庫中存儲(chǔ)圖片、文件等大數(shù)據(jù)
• 禁止使用order by rand()，類似的有很多替代方案
• 禁止使用SELECT *，根據(jù)需要獲取相對(duì)應(yīng)需要的字段
• 禁止使用預(yù)留字段，無論從流程和規(guī)范上都說不過去
• 禁止在MySQL中進(jìn)行數(shù)學(xué)運(yùn)算和函數(shù)運(yùn)算
• 禁止隱式轉(zhuǎn)換，數(shù)值類型禁止加引號(hào)，字符串類型必須加引號(hào)
• 禁止使用 INSERT INTO TABLE()，需要指定相應(yīng)的字段，最好是順序的
• 禁止使用前置百分號(hào)，例如：WHERE A LIKE ‘%B’
• 禁止使用 NOT 查詢，例如 NOT IN、!=、NOT LIKE
• 禁止單條SQL語句同時(shí)更新多個(gè)表
• 禁止使用存儲(chǔ)過程、觸發(fā)器、視圖、自定義函數(shù)等
• 禁止在從庫上執(zhí)行負(fù)責(zé)統(tǒng)計(jì)類查詢，使用專用從庫
• 禁止在數(shù)據(jù)庫中存儲(chǔ)明文密碼

5、注意什么

• 合并對(duì)于單表多次的操作
• 表結(jié)構(gòu)變更必須通知DBA審核參與
• 重要項(xiàng)目的數(shù)據(jù)庫方案選型和設(shè)計(jì)必須提前通知DBA參與
• 禁止在線上做數(shù)據(jù)庫壓力測試
• 禁止從測試、開發(fā)環(huán)境直連線上數(shù)據(jù)庫
• 禁止有超級(jí)權(quán)限的應(yīng)用程序賬號(hào)存在
• 禁止有DDL、DCL權(quán)限的應(yīng)用程序賬號(hào)存在
• 批量導(dǎo)入、導(dǎo)出數(shù)據(jù)必須通過DBA審核，并在執(zhí)行過程中觀察服務(wù)
• 批量更新數(shù)據(jù)，如UPDATE、DELETE操作，必須DBA進(jìn)行審核，并在執(zhí)行過程中觀察服務(wù)
• 產(chǎn)品出現(xiàn)非數(shù)據(jù)庫導(dǎo)致的故障時(shí)，如被攻擊，必須及時(shí)通DBA，便于維護(hù)服務(wù)穩(wěn)定
• 業(yè)務(wù)部門程序出現(xiàn)BUG等影響數(shù)據(jù)庫服務(wù)的問題，必須及時(shí)通知DBA，便于維護(hù)服務(wù)穩(wěn)定
• 業(yè)務(wù)部門推廣活動(dòng)或上線新功能，必須提前通知DBA進(jìn)行服務(wù)和訪問量評(píng)估，并留出必要時(shí)間以便DBA完成擴(kuò)容
• 出現(xiàn)業(yè)務(wù)部門人為誤操作導(dǎo)致數(shù)據(jù)丟失，需要恢復(fù)數(shù)據(jù)的，必須第一時(shí)間通知DBA，并提供準(zhǔn)確時(shí)間點(diǎn)、 誤操作語句等重要線索
• 提交線上建表改表需求，必須詳細(xì)注明涉及到的所有SQL語句(包括INSERT、DELETE、UPDATE)，便于DBA進(jìn)⾏行審核和優(yōu)化

以上相對(duì)比較常規(guī)，一個(gè)完善合理的規(guī)范當(dāng)然還需要一個(gè)比較長的過程。

四、MySQL之系統(tǒng)規(guī)劃

1、環(huán)境規(guī)劃

MySQL作為流行的開源數(shù)據(jù)庫擁有多個(gè)重要分支，每個(gè)分支都有各自的優(yōu)缺點(diǎn)，這里不做過多評(píng)價(jià)，總的來說，MySQL仍然是一款非常出色的產(chǎn)品，是一個(gè)非常適合大多數(shù)場景下使用的數(shù)據(jù)庫，無論是從可用性、可擴(kuò)展性、性能和管理各方面都是不錯(cuò)的選擇。

當(dāng)然說為了追求某些方面的新的功能性需求，或者M(jìn)ySQL版本覺得太臃腫，你也可以嘗試其他版本，主要是符合你的業(yè)務(wù)場景才是最合適的。

根據(jù)研發(fā)的階段來劃分主要分為開發(fā)階段、測試階段、準(zhǔn)生產(chǎn)階段、壓測階段、上線階段。

開發(fā)階段-開發(fā)環(huán)境

數(shù)據(jù)庫和系統(tǒng)的版本可能都比較新，這里面有一部分是嘗鮮的概念在里面，同時(shí)，也為了以后的版本更新提供了一定的基礎(chǔ)，其次是研發(fā)人員對(duì)于數(shù)據(jù)庫和操作系統(tǒng)的權(quán)限是比較大的，基本上會(huì)all in，主要保證開發(fā)的進(jìn)度。

測試階段-測試環(huán)境

這個(gè)環(huán)境的版本可能也是比較新的，不過已經(jīng)很貼近生產(chǎn)了，然后是對(duì)于權(quán)限的話，由于主要是測試階段，研發(fā)人員和測試人員的權(quán)限基本上限定到庫表的DML權(quán)限，很難執(zhí)行其它特別是DDL操作了，當(dāng)然還是以保證開發(fā)和測試為主。

準(zhǔn)生產(chǎn)階段-準(zhǔn)生產(chǎn)環(huán)境

原則上這個(gè)環(huán)境跟生產(chǎn)環(huán)境基本上1：1，版本跟生產(chǎn)是一樣的，其次配置比生產(chǎn)會(huì)低很多，權(quán)限的話，已經(jīng)不允許DDL語句了，并且DML也會(huì)嚴(yán)格控制。

壓測階段–壓測環(huán)境

一般化而言，很多公司會(huì)把準(zhǔn)這個(gè)壓測環(huán)境放到準(zhǔn)生產(chǎn)上面，對(duì)此，我不反對(duì)不建議，完全看你的想法和公司的規(guī)劃，壓測環(huán)境跟生產(chǎn)環(huán)境保證100%完全一致性，因?yàn)闉榱俗非竽莻€(gè)極致，同時(shí)全面禁止的DDL，只讀環(huán)境。

PS：很多時(shí)候，你的準(zhǔn)生產(chǎn)可能就是壓測環(huán)境，這邊就不做過多說明了，主要還是看你的規(guī)劃。

上線階段–線上環(huán)境

這個(gè)就不說了，完全禁止的DML、DDL操作，任何操作必須有記錄，比如審計(jì)、工單等等。

2、容量規(guī)劃

容量規(guī)劃主要是如何有效評(píng)估需求，如果說沒有統(tǒng)一綜合的管理機(jī)制，各種項(xiàng)目的資源申請(qǐng)各自為政，沒有考慮到綜合實(shí)際使用的資源情況，會(huì)造成嚴(yán)重的分配問題，或者說資源不足，有可能部分項(xiàng)目的提前預(yù)支超過實(shí)際情況的資源，其它項(xiàng)目完全沒有資源，或者項(xiàng)目資源是有時(shí)間期限的，過了期限就需要即使的回收利用。

對(duì)于數(shù)據(jù)庫本身容量規(guī)劃更加重要，畢竟你的數(shù)據(jù)都在里面，首先項(xiàng)目初始階段可能會(huì)預(yù)估下使用量，然后還需要定期的實(shí)際評(píng)估，根據(jù)資源的使用情況及時(shí)調(diào)整，綜合規(guī)劃各個(gè)項(xiàng)目的資源配置。

MySQL的容量規(guī)劃主要是庫表的大小，這個(gè)主要是看業(yè)務(wù)量，很多時(shí)候業(yè)務(wù)部門會(huì)說我的計(jì)劃目標(biāo)是1kw用戶量，那么可能很難有一個(gè)估計(jì)的大小，因?yàn)槟愕膸毂硪恢笔窃谧兓模匀欢?，比較困難評(píng)估一個(gè)大概的容量，而且如果數(shù)據(jù)量太大的情況下，從數(shù)據(jù)的訪問響應(yīng)速度就需要考慮分庫分表了，這個(gè)主要還是看的業(yè)務(wù)場景和需要的響應(yīng)速度。

3、文件規(guī)劃

MySQL數(shù)據(jù)文件目錄還是比較簡單的，可以分成數(shù)據(jù)文件目錄、日志文件目錄、參數(shù)文件目錄、其它文件目錄等。

數(shù)據(jù)文件目錄

數(shù)據(jù)文件主要按照庫表單位劃分的，由于引擎的不同可能分成結(jié)構(gòu)定義文件、數(shù)據(jù)文件、索引文件。

日志文件目錄

這里面包括了啟動(dòng)日志、報(bào)錯(cuò)日志、查詢?nèi)罩?、慢查詢?nèi)罩尽inlog日志、binlog索引文件、relay_log中繼日志、relay_log中繼日志索引文件等。

參數(shù)文件目錄

包括pid、sock、cnf 文件等。

其他文件目錄

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

歸檔，這邊說的歸檔規(guī)劃是定期把以上各類文件備份歸檔，數(shù)據(jù)文件自不必說，其它文件也是需要定期歸檔的，歸檔的方法有很多，你可以把相應(yīng)的文件根據(jù)不同的規(guī)律存放在結(jié)構(gòu)化或者非結(jié)構(gòu)化的地方。

4、審計(jì)規(guī)劃

數(shù)據(jù)庫審計(jì)能夠?qū)崟r(shí)記錄網(wǎng)絡(luò)上的數(shù)據(jù)庫活動(dòng)，對(duì)數(shù)據(jù)庫操作進(jìn)行細(xì)粒度審計(jì)的合規(guī)性管理，對(duì)數(shù)據(jù)庫遭受到的風(fēng)險(xiǎn)行為進(jìn)行告警，對(duì)攻擊行為進(jìn)行阻斷。

它通過對(duì)用戶訪問數(shù)據(jù)庫行為的記錄、分析和匯報(bào)，用來幫助用戶事后生成合規(guī)報(bào)告、事故追根溯源，同時(shí)加強(qiáng)內(nèi)外部數(shù)據(jù)庫網(wǎng)絡(luò)行為記錄，提高數(shù)據(jù)安全。

審計(jì)對(duì)數(shù)據(jù)庫記錄和行為進(jìn)行獨(dú)立的審查和估計(jì)，其主要作用和目的包括以下幾個(gè)方面：

• 對(duì)可能存在的潛在攻擊者起到威懾和警示作用，核心是風(fēng)險(xiǎn)評(píng)估。
• 測試系統(tǒng)的控制情況，及時(shí)進(jìn)行調(diào)整，保證與安全策略和操作規(guī)程協(xié)調(diào)一致。
• 對(duì)已出現(xiàn)的破壞事件，做出評(píng)估并提供有效的災(zāi)難恢復(fù)和追究責(zé)任的依據(jù)。
• 對(duì)系統(tǒng)控制、安全策略與規(guī)程中的變更進(jìn)行評(píng)價(jià)和反饋，以便修訂決策和部署。
• 協(xié)助系統(tǒng)管理員及時(shí)發(fā)現(xiàn)網(wǎng)絡(luò)系統(tǒng)入侵或潛在的系統(tǒng)漏洞及隱患。

有個(gè)不知道算奇怪還是正常的事情，不知道多少人給生產(chǎn)恢復(fù)過數(shù)據(jù)，這里面不談因由，只有做過的人才知道這其中的坑有多少，所以也就需要大家對(duì)于各種恢復(fù)手段都有所了解，乃至于熟練掌握。

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

對(duì)于數(shù)據(jù)庫而言，無論是硬件設(shè)備還是軟件審計(jì)都會(huì)加大數(shù)據(jù)庫的壓力，從性能的損耗上講，事后審計(jì)是比較折中的策略，這邊先講下軟件部分的，無論是MySQL官方還是MariaDB或者Percona還是其它的都有一套自己的審計(jì)產(chǎn)品。

下面列下常用的幾種：

• 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)

主要用哪個(gè)還得看你適合哪個(gè)，如果你有足夠的資源可以考慮采用硬件的模式，盡量選擇專門審計(jì)設(shè)備的設(shè)備，然后根據(jù)定期的報(bào)表檢查你的相關(guān)配置。

前面列出的幾個(gè)感興趣的小伙伴可以具體測試下，當(dāng)然如果你已經(jīng)在使用了，那我們可以私下交流。

5、備份恢復(fù)規(guī)劃

• 備份和恢復(fù)是兩個(gè)相互關(guān)聯(lián)的，至于備份恢復(fù)的種種前面已經(jīng)有說過了，關(guān)于備份恢復(fù)也有一系列的軟硬件，這邊主要說下規(guī)劃。
• 你首選要根據(jù)自己的實(shí)際情況做需求分析，你需要有當(dāng)前使用數(shù)據(jù)庫的類型、版本信息、配置信息、數(shù)據(jù)量總大小、每日新增大小、備份方式(物理備份/邏輯備份)、業(yè)務(wù)高峰期，當(dāng)然還有數(shù)據(jù)庫的主機(jī)的系統(tǒng)情況等信息。
• 備份策略，根據(jù)不同的業(yè)務(wù)還有其它需要確定，常用的是全量、增量、差異備份三種，實(shí)際情況下很多都是三種策略的結(jié)合使用。
• 備份大小，這個(gè)取決于你采用的備份方式，會(huì)有一個(gè)大致的增長值，這個(gè)可能需要跟業(yè)務(wù)那邊的規(guī)劃做詳細(xì)的統(tǒng)計(jì)，給出一個(gè)大概的范圍。
• 備份保留時(shí)間，這個(gè)跟備份的大小、備份介質(zhì)的大小、性價(jià)比有關(guān)系。
• 如果你的介質(zhì)空間太小，自然而然也就不能保留太長時(shí)間，這個(gè)時(shí)候，通常會(huì)根據(jù)業(yè)務(wù)的核心程度來劃分，應(yīng)確定重要業(yè)務(wù)備份的保存期以及其它需要永久保存的備份，總的來說，保留半年之類的有效數(shù)據(jù)是基本的要求。
• 備份介質(zhì)大小，根據(jù)你的保留時(shí)間合理地規(guī)劃你的備份介質(zhì)大小。
• 備份計(jì)劃，這個(gè)跟恢復(fù)策略有關(guān)系，基本上是你需要一個(gè)專門備份的數(shù)據(jù)庫，這個(gè)主要是為了減少對(duì)主庫的影響，對(duì)此大部分是數(shù)據(jù)庫都支持該方案，當(dāng)然主庫執(zhí)行備份也不是不可以，只要合理使用。
• 根據(jù)業(yè)務(wù)繁忙的情況，在合理的時(shí)間和空間下能全備的盡量全備，雖然全量可能會(huì)增加數(shù)據(jù)的重復(fù)性和空間的使用，你可以適當(dāng)加上增量或者差異備份。
• 太大的庫可能全備時(shí)間太長，優(yōu)化過后還是不能接受，可以選擇一個(gè)相對(duì)不繁忙的時(shí)間做全量備份，然后加上增量或者差異備份，當(dāng)然這個(gè)全量的頻率還是需要根據(jù)你的業(yè)務(wù)來結(jié)合?？偛荒苷f，我需要恢復(fù)昨天的數(shù)據(jù)，你告訴我只有上上上個(gè)月的全備加上增量或者差異，這個(gè)恢復(fù)的時(shí)間一般會(huì)比較長，這個(gè)肯定不能滿足的需求，所以備份計(jì)劃要完全貼合你的業(yè)務(wù)需求，以及需要詳細(xì)指定最大容忍的時(shí)間性要求。
• 備份執(zhí)行過程應(yīng)有詳細(xì)的規(guī)劃和記錄，包括備份重要等級(jí)、備份主體、備份時(shí)間、備份策略、備份路徑、記錄介質(zhì)(類型)等。
• 同時(shí)備份文件加密權(quán)限控制也是不可或缺的，所有操作需要保留相應(yīng)記錄，方便審計(jì)跟蹤，安全需要時(shí)刻關(guān)注。
• 恢復(fù)規(guī)劃，這個(gè)不能說是規(guī)劃，我覺得這個(gè)應(yīng)該更像一個(gè)日常的計(jì)劃任務(wù)，如果你有充足的資源，特別的恢復(fù)服務(wù)器組，我希望你在每天完成備份并且上傳統(tǒng)一的備份介質(zhì)后，每天都可以把所有的系統(tǒng)都恢復(fù)一次，不要覺得太麻煩，有時(shí)候這些麻煩會(huì)幫你很多，當(dāng)你把所有的一切做成定時(shí)任務(wù)之后，你會(huì)發(fā)現(xiàn)，生活太美好。

實(shí)際的情況往往比這個(gè)更加復(fù)雜，我們把容災(zāi)劃分成很多的等級(jí)，計(jì)算機(jī)軟件故障、人為原因、計(jì)劃性停機(jī)，然后從等級(jí)上是時(shí)間上有幾個(gè)九，同時(shí)還有災(zāi)備的環(huán)境一些措施，確?？梢栽谝?guī)定的時(shí)間內(nèi)完成有效性恢復(fù)。

但是，當(dāng)災(zāi)難發(fā)生的時(shí)候，很多東西都會(huì)很巧合地并發(fā)發(fā)生，會(huì)很亂，假使災(zāi)備環(huán)境也不是正常的或者壓根就沒有所謂的災(zāi)備環(huán)境，那個(gè)時(shí)候你依賴的可能也僅僅是備份的一個(gè)有效恢復(fù)，那個(gè)時(shí)候，壓力會(huì)稍微有點(diǎn)大，如果你對(duì)恢復(fù)情況不是很了解，或者不是很熟練，我們也只能就這么看著能恢復(fù)多少，心里沒有底，這個(gè)時(shí)候才會(huì)覺得恢復(fù)測試真的非常重要。

平時(shí)我們關(guān)注的大都在日常的備份上，并不會(huì)實(shí)際去驗(yàn)證，不過其實(shí)日?；謴?fù)演練更加重要，即使不能做到所有系統(tǒng)的恢復(fù)計(jì)劃，起碼保證核心系統(tǒng)的備份的有效性，同時(shí)制定恢復(fù)測試計(jì)劃。

總結(jié)

總之，對(duì)于數(shù)據(jù)庫而言，首先要求我們擁有一個(gè)完整的備份，有了備份你才能做很多事，同時(shí)也會(huì)省了很多事。其次是安全，無論是數(shù)據(jù)備份的安全還是數(shù)據(jù)本身或者研發(fā)使用中的安全，都值得關(guān)注。然后是數(shù)據(jù)庫本身的使用，合情合理的使用。最后對(duì)于你所維護(hù)的數(shù)據(jù)庫你需要擁有詳細(xì)的規(guī)劃，無論是管理角度還是使用角度都需要。

最后給大家提幾點(diǎn)建議：

• 未雨綢繆，不要停留在制度上，而是實(shí)際做出來。
• 亡羊補(bǔ)牢，舉一反三，切記，不能好了傷疤忘了疼。
• 完備的架構(gòu)設(shè)計(jì)及備份，恢復(fù)策略及備份驗(yàn)證策略。
• 定期思考，并實(shí)戰(zhàn)模擬以上策略演練。
• 實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)。

一家之言，姑妄聽之，如有疏漏錯(cuò)誤的，歡迎大家一起探討。