《做了這么久的 DBA，你真的認(rèn)識(shí) MySQL 數(shù)據(jù)安全體系？》要點(diǎn)：
本文介紹了做了這么久的 DBA，你真的認(rèn)識(shí) MySQL 數(shù)據(jù)安全體系？，希望對(duì)您有用。如果有疑問，可以聯(lián)系我們。

作者介紹：

強(qiáng)昌金

去哪兒網(wǎng) 高級(jí)DBA2015年加入去哪兒,擔(dān)任MySQL DBA,主要負(fù)責(zé)去哪兒數(shù)據(jù)庫管理平臺(tái)的開發(fā)、MySQL和Redis的運(yùn)維.在數(shù)據(jù)庫方面,具有豐富的數(shù)據(jù)庫運(yùn)維、性能優(yōu)化經(jīng)驗(yàn).

給大家分享下有關(guān)MySQL在數(shù)據(jù)安全的話題,怎么通過一些配置來保證數(shù)據(jù)安全以及保證數(shù)據(jù)的存儲(chǔ)落地是安全的.

我是在2014年加入陌陌,2015年加入去哪兒網(wǎng),做MySQL的運(yùn)維,包括自動(dòng)化的開發(fā).

接下來我將從四個(gè)方面給大家介紹一下,數(shù)據(jù)庫怎么通過一些配置做到數(shù)據(jù)安全的.

• 單機(jī)安全

• 集群安全

• 備份安全

• 發(fā)展

現(xiàn)在的行業(yè)中,數(shù)據(jù)是一個(gè)非常重要的資產(chǎn).

數(shù)據(jù)是怎么保證安全呢?在日常中,大家都認(rèn)為一些商業(yè)的數(shù)據(jù)庫能更好的保證數(shù)據(jù)安全.他們認(rèn)為對(duì)于新興的MySQL來說,一致認(rèn)為可以在互聯(lián)網(wǎng)使用,因?yàn)榛ヂ?lián)網(wǎng)的數(shù)據(jù)丟了也就無所謂了,我感覺他們這是對(duì)MySQL數(shù)據(jù)庫的一個(gè)誤解.

我所說的數(shù)據(jù)安全是指數(shù)據(jù)落地的安全,而不是遭到黑客攻擊,也不包括網(wǎng)絡(luò)安全.

在企業(yè)剛開始起步的時(shí)候有可能資源有限,只使用單機(jī),這時(shí)候單機(jī)有可能部署一個(gè).

隨著企業(yè)的發(fā)展,有可能單機(jī)會(huì)存在數(shù)據(jù)崩潰的問題,這將導(dǎo)致整個(gè)數(shù)據(jù)不可用的.因此就會(huì)往集群化的方向發(fā)展,會(huì)利用主從模式,保證數(shù)據(jù)分布到多個(gè)節(jié)點(diǎn),即使某個(gè)節(jié)點(diǎn)崩潰后,還有其他節(jié)點(diǎn)是可用的.

這樣就能保證真正的數(shù)據(jù)不丟嗎?有可能機(jī)房出現(xiàn)了網(wǎng)絡(luò)故障,或者整個(gè)機(jī)房宕機(jī)了.今年也遇到過很多整個(gè)數(shù)據(jù)不可用,備份也不可用的情況,這時(shí)候數(shù)據(jù)就丟失了.

為了更好的是保證數(shù)據(jù)安全,要進(jìn)行備份.要對(duì)數(shù)據(jù)進(jìn)行本地備份和遠(yuǎn)程備份,這樣集群不可用的時(shí)候利用備份進(jìn)行恢復(fù).

第四方面,介紹一下MySQL基本的發(fā)展.

下面詳細(xì)的對(duì)這四個(gè)部分來進(jìn)行闡述.

一. 單機(jī)安全

單機(jī)安全會(huì)涉及到兩個(gè)配置參數(shù)：

• Double Write

• innodb_flush_log_at_trx_commit

下面詳細(xì)說明.

1.1 Double Write

我們企業(yè)在剛剛起步的時(shí)候只有一個(gè)節(jié)點(diǎn),怎么保證我們的數(shù)據(jù)落盤?在MySQL宕機(jī)或者系統(tǒng)宕機(jī)數(shù)據(jù)庫啟動(dòng)的時(shí)候它能夠啟起來.在啟動(dòng)過程中,他們會(huì)檢測(cè)數(shù)據(jù)頁是否是正常的,這時(shí)候我們會(huì)引入一個(gè)叫Double Write.

什么叫Double Write?對(duì)一個(gè)頁面的所有操作,包括頁頭、頁面等等,這原本是物理的操作.但是為了節(jié)約日志量,把它改成邏輯的,就會(huì)記錄包括空間數(shù)、內(nèi)容字段等等,等到有必要的時(shí)候才真正的將這些邏輯寫變成物理寫.

在寫的過程中,首先保證所寫的頁面是正確的.如果一個(gè)頁面在寫的過程中由于多次寫導(dǎo)致頁面斷裂,這樣就不可寫.這時(shí)候我們就需要一個(gè)Double Write,等于現(xiàn)在一個(gè)是鏡像,另一個(gè)是備份.

MySQL 5.7之前有一個(gè)2M的緩存.如果在校驗(yàn)的過程中,這個(gè)頁面有問題,就會(huì)利用Double Write將兩個(gè)頁面進(jìn)行拷貝回來,這樣我們的數(shù)據(jù)庫就恢復(fù)到可用的狀態(tài).

四個(gè)問題：

• 兩次寫本身頁面斷裂會(huì)不會(huì)有問題?它所要操作頁面之前,記錄的是數(shù)據(jù)庫之前的狀態(tài)是一致的.這時(shí)頁面出現(xiàn)問題,本身就不會(huì)去寫入了,就不會(huì)出現(xiàn)問題.

• 最近數(shù)據(jù)是不是一直在覆蓋?因?yàn)槲覀冎乐挥?M的空間,因此會(huì)一直覆蓋去寫.

• 性能問題?我們知道在Double Write有兩次寫的.這對(duì)我們的操作是不是也有兩次?我們知道它有一個(gè)緩存空間,當(dāng)緩存空間滿的時(shí)候,會(huì)將邏輯寫變成順序?qū)?這對(duì)磁盤的影響是比較小的,不會(huì)導(dǎo)致性能消耗,但是也會(huì)帶來一點(diǎn)點(diǎn)性能消耗.

• 可不可以沒有Double Write?有可能.

1.2 innodb_flush_log_at_trx_commit

數(shù)據(jù)庫宕機(jī)分為兩種情況：

• 數(shù)據(jù)庫宕機(jī)服務(wù)器正常

• 服務(wù)器宕機(jī)

在宕機(jī)的時(shí)候,對(duì)提交到數(shù)據(jù)庫的事務(wù)如果沒有寫到redo log文件中,數(shù)據(jù)就會(huì)丟失.

innodb_flush_log_at_trx_commit參數(shù)的三個(gè)值的策略：

這三個(gè)參數(shù)對(duì)數(shù)據(jù)庫宕機(jī)是不是會(huì)導(dǎo)致數(shù)據(jù)的丟失呢?

在值為0的時(shí)候,每秒寫入,在數(shù)據(jù)庫宕機(jī)或者系統(tǒng)宕機(jī)時(shí),都會(huì)有數(shù)據(jù)的丟失的.

在值為1的時(shí)候,每次操作都會(huì)去寫入到真正的redo log的磁盤文件中,這時(shí)候不管數(shù)據(jù)庫宕機(jī)還是操作系統(tǒng)宕機(jī),都不會(huì)丟失.在啟動(dòng)的時(shí)候,redo log在文件中是可以進(jìn)行恢復(fù)的.

在值為2的時(shí)候,是刷到操作系統(tǒng)的cache中,數(shù)據(jù)庫宕機(jī)了,但是操作系統(tǒng)是完整的,能夠?qū)懭氲酱疟P中,這時(shí)候數(shù)據(jù)是不會(huì)丟失的.

二. 集群安全

在單機(jī)的過程中,通過兩個(gè)參數(shù)保證我們的數(shù)據(jù)落盤.然而,有可能服務(wù)器宕機(jī)了,再也啟動(dòng)不起來了,這時(shí)我們的數(shù)據(jù)等于是全部丟失了,或者可以利用備份數(shù)據(jù)進(jìn)行恢復(fù)一部分的數(shù)據(jù),這種情況對(duì)我們的企業(yè)就會(huì)導(dǎo)致一定的影響.

• 主從復(fù)制

• 異步復(fù)制

• 半同步復(fù)制

• MySQL Galera Cluster

此時(shí),我們可以通過集群的模式,如搭建一主多從或者多主等等,來保證我們的數(shù)據(jù)在多個(gè)節(jié)點(diǎn)都有的,即使一個(gè)節(jié)點(diǎn)宕機(jī)以后,可以把讀寫服務(wù)切換到另一個(gè)節(jié)點(diǎn),保證數(shù)據(jù)可用的.

2.1. 主從復(fù)制

2.1.1 sync_binlog

主從復(fù)制是異步的模式.

在默認(rèn)情況下,我們都會(huì)使用簡(jiǎn)單的主從復(fù)制進(jìn)行保證一主多節(jié)點(diǎn)進(jìn)行同步.

在復(fù)制過程中最重要的一個(gè)東西就是sync_binlog,它在等于0的時(shí)候,每次刷新到cache中；等于1的時(shí)候會(huì)同步到磁盤中.

這個(gè)參數(shù)對(duì)數(shù)據(jù)丟失的影響：

同樣數(shù)據(jù)庫宕機(jī)分兩種,一種是系統(tǒng)的宕機(jī),一種是數(shù)據(jù)庫宕機(jī).數(shù)據(jù)庫宕機(jī)已經(jīng)寫入到OS的cache中,因此不會(huì)丟失.如果恰好這時(shí)操作系統(tǒng)宕機(jī),就等于丟失OS cache了,如果sync_binlog 值為0,將會(huì)丟失數(shù)據(jù)了.

2.1.2 binlog_format

二進(jìn)制日志格式有三種：

• STATEMENT

• MIXED

• ROW

我們現(xiàn)在主要使用ROW格式,會(huì)存在一個(gè)問題,就是我們?nèi)罩玖繒?huì)稍微大一些.

2.1.3 與復(fù)制POS點(diǎn)相關(guān)參數(shù)

在主從復(fù)制過程中,有兩個(gè)重要的文件:

• 一個(gè)是記錄master-info

• 一個(gè)是記錄relay-log-info

從MySQL 5.7版本,已經(jīng)使用表結(jié)構(gòu)了,建議這么做.

這兩個(gè)sync-master-info和sync-relay-log-info參數(shù),如果存在宕機(jī),我們能知道之前復(fù)制的點(diǎn)在什么位置.

relay_log_recovery個(gè)參數(shù),如果設(shè)置為1,它會(huì)找到MySQL線程最新執(zhí)行的最后的位置,然后利用那個(gè)位置,重新創(chuàng)新一個(gè)relay-log,這個(gè)值對(duì)我們來講非常重要.如果不設(shè)為1,會(huì)導(dǎo)致我們?cè)趩?dòng)過程中,點(diǎn)不是最新的點(diǎn),會(huì)導(dǎo)致事物的沖突,甚至?xí)?dǎo)致主從復(fù)制的沖突.

2.2 半同步

主要說說一下三點(diǎn)：

• 半同步復(fù)制特性

• 半同步與異步對(duì)比

• 半同步參數(shù): rpl_semi_sync_master_wait_point

2.2.1 半同步復(fù)制特性

主庫和從庫會(huì)存在延時(shí)的,可能從庫沒有接收到主庫的binlog信息.

MySQL 推出了一個(gè)半同步復(fù)制,就是主庫會(huì)等待從庫中至少一個(gè)節(jié)點(diǎn),是否真正的獲取到binlog日志,并且刷新到redo log文件中.

半同步有哪些特性呢?

• 從庫告知主庫是否為半同步

• 主庫事務(wù)提交會(huì)被阻塞

• 從庫寫入relay log后通知主庫

• 主庫等待超時(shí)后,自動(dòng)轉(zhuǎn)換為異步復(fù)制

• 主從必須同時(shí)開啟半同步

首先會(huì)告訴主庫自己是否配置了半同步,并且主庫提交事物的時(shí)候,這個(gè)線程會(huì)進(jìn)行阻塞,等待從庫進(jìn)行回復(fù).如果真的沒有回復(fù),它會(huì)把這個(gè)從庫降成異步復(fù)制.如果有回復(fù),進(jìn)行確認(rèn)后,主庫的線程就會(huì)繼續(xù)做其他的事務(wù),那么在這個(gè)過程中,它是會(huì)被阻塞掉的.

從庫接收到主庫的binlog后,會(huì)寫入到redo log.

在半同步的復(fù)制過程中,每個(gè)事務(wù)提交的時(shí)候,會(huì)等待至少一個(gè)從節(jié)點(diǎn),如果從節(jié)點(diǎn)已經(jīng)獲取到了binlog,這時(shí)候主節(jié)點(diǎn)才會(huì)真正的提交做后續(xù)的操作,這時(shí)候就可以保證至少有一個(gè)節(jié)點(diǎn)是和主節(jié)點(diǎn)的數(shù)據(jù)是一致的.

2.2.2 半同步復(fù)制特性

最主要的區(qū)別在于半同步復(fù)制能保證至少一個(gè)從節(jié)點(diǎn)會(huì)與主節(jié)點(diǎn)數(shù)據(jù)一致性.

2.2.3 rpl_semi_sync_master_wait_point

在半同步過程中,有一個(gè)重要的參數(shù)rpl_semi_sync_master_wait_point來進(jìn)行控制,就是主庫的線程提交事務(wù)后,在整個(gè)進(jìn)程進(jìn)行等待還是在提交事務(wù)以后再去等待.

首先講一下這兩個(gè)配置有什么影響.

AFTER_COMMIT提交完進(jìn)入等待狀態(tài),等待一個(gè)從庫,現(xiàn)場(chǎng)回復(fù)一個(gè)ACP確認(rèn).從庫匯報(bào)了ACP確認(rèn)后,進(jìn)入后續(xù)的狀態(tài),就是將結(jié)果通知到客戶端.

在這個(gè)狀態(tài)的情況下,可能會(huì)導(dǎo)致從庫丟數(shù)據(jù),之所以這樣是因?yàn)槲覀冊(cè)谝鎸右呀?jīng)提交了,這時(shí)候我們?cè)诘却倪^程中,其實(shí)在這個(gè)主庫上的其它會(huì)話是能夠知道這個(gè)事務(wù)已經(jīng)提交的結(jié)果.但是如果此時(shí)主庫還在等待過程中主庫宕機(jī)了,并且不可恢復(fù),這時(shí)從庫有可能沒有接收到數(shù)據(jù)的,在主庫上它認(rèn)為這個(gè)事務(wù)已經(jīng)提交成功了,就會(huì)導(dǎo)致從庫根本沒有拿到這個(gè)binlog,因此會(huì)丟失這個(gè)事務(wù)的數(shù)據(jù).

為了解決這個(gè)問題,在MySQL 5.7會(huì)推出另外一種狀態(tài)進(jìn)行等待—-AFTER_SYNC,就是同步完立馬進(jìn)行等待.

如果這時(shí)候主庫宕機(jī)了,從庫有可能接收到這個(gè)binlog,并且應(yīng)用到從庫的數(shù)據(jù)庫中,這時(shí)主庫還沒有進(jìn)入到提交,因此主庫的數(shù)據(jù)是沒有提交的,有可能從庫會(huì)多出一部分?jǐn)?shù)據(jù).

我個(gè)人認(rèn)為,多出的數(shù)據(jù),總比丟失的好.當(dāng)我們的服務(wù)切入到從庫,服務(wù)在處理的過程中,會(huì)根據(jù)多出來的數(shù)據(jù)做相應(yīng)的處理,總比沒有相對(duì)來說更好一些.

2.3 MySQL Galera Cluster

上面說的主從復(fù)制,不管使用異步復(fù)制還是半同步復(fù)制,都可能出現(xiàn)丟失數(shù)據(jù)的問題.去哪兒網(wǎng),經(jīng)過幾年的發(fā)展,多年的研究,大量的在使用Galera Cluster.

MySQL Galera Cluster 注意點(diǎn)：

• 基于binlog復(fù)制模式

• DDL執(zhí)行卡死

• DDL優(yōu)先

• DDL執(zhí)行過程中不能退出

• Flow Control

在支付的業(yè)務(wù)中,我們要強(qiáng)烈要求數(shù)據(jù)是一致性的,這時(shí)候PRC能夠非常好的滿足這個(gè)特點(diǎn).包括多點(diǎn)寫入,在日常維護(hù)中經(jīng)常遇到一個(gè)問題,有可能需要重啟數(shù)據(jù)庫,或者遷移數(shù)據(jù)庫.

主從復(fù)制的架構(gòu),需要將業(yè)務(wù)的讀寫請(qǐng)求切換到另外一個(gè)節(jié)點(diǎn).如果流量慢慢切入到別的節(jié)點(diǎn)就OK了,這時(shí)對(duì)業(yè)務(wù)的影響幾乎是沒有的,所以我們可以非常大膽的做一些切換操作.

double write如果我們沒有開,有可能數(shù)據(jù)庫就啟動(dòng)不起來,啟動(dòng)不起來也沒有任何問題,因?yàn)橄喈?dāng)于這個(gè)新的節(jié)點(diǎn)加入到PCRC的過程中,就會(huì)執(zhí)行一個(gè)SYNC的操作,會(huì)把數(shù)據(jù)拉取過來,只不過數(shù)據(jù)恢復(fù)的時(shí)間較長(zhǎng)一些.

redo log這個(gè)參數(shù)是為了可以提高一些性能.sync-binlog,甚至binlog都不用開.

有了集群,這時(shí)候?qū)I(yè)務(wù)來說,對(duì)企業(yè)來說,應(yīng)該比較放心了,數(shù)據(jù)應(yīng)該不會(huì)丟失了.但是,今年出現(xiàn)了好幾個(gè)案例,就是數(shù)據(jù)庫機(jī)房宕機(jī),或者集群宕機(jī)以后,沒有備份可以用了,所有的數(shù)據(jù)都丟失了,我們只能強(qiáng)烈的依賴于備份.

今年上半年出現(xiàn)了兩個(gè)比較大的故障,就是連備份都不可用了.這時(shí)候備份安全對(duì)我們企業(yè),對(duì)我們業(yè)務(wù)來說是非常重要的.

三. 備份安全

備份中分為兩個(gè)：

• 數(shù)據(jù)備份

• binlog備份

數(shù)據(jù)備份中,我們可以每天對(duì)數(shù)據(jù),對(duì)整個(gè)機(jī)器的數(shù)據(jù)進(jìn)行一個(gè)鏡像,或者用別的MySQL Double等等進(jìn)行備份.

binlog有可能我們?cè)跀?shù)據(jù)備份的時(shí)候也只是備份某一點(diǎn)的數(shù)據(jù)備份,在這次備份到下次備份之間,這種數(shù)據(jù)是怎么恢復(fù)呢?我們可以用binlog.

3.1 數(shù)據(jù)備份

備份方式分為：

• 冷備

• 熱備

備份工具分為：

• 邏輯備份工具

• mysqldump

• mysqldumper

• mysqlpump

• select … into outfile

• 物理備份工具

• InnoDB ibbackup

• Percona XtraBackup

邏輯備份工具,就是把dump文件保存起來,這會(huì)存在一個(gè)問題,有可能dump的時(shí)間很長(zhǎng),恢復(fù)的時(shí)間也就很長(zhǎng)了.

這在整個(gè)數(shù)據(jù)庫想要依賴于這個(gè)備份節(jié)點(diǎn)恢復(fù)的時(shí)候,整個(gè)業(yè)務(wù)等待的時(shí)間就很長(zhǎng)了.如果用邏輯備份,恢復(fù)時(shí)間越長(zhǎng),對(duì)業(yè)務(wù)的影響越大.所以,我們盡量采用一個(gè)物理的備份,如XtraBckup.

備份存儲(chǔ)分為：

• 本地存儲(chǔ)

• 遠(yuǎn)程存儲(chǔ)

我們的備份數(shù)據(jù)庫存儲(chǔ)在本地的服務(wù)器上的話,可能存在備份文件不可用了,會(huì)導(dǎo)致數(shù)據(jù)的丟失.

因此,我們要優(yōu)先考慮遠(yuǎn)程備份,可以把MySQL數(shù)據(jù)文件備份到異地的機(jī)房.

3.2 binlog備份

有了數(shù)據(jù)備份后,它只是某個(gè)點(diǎn)的鏡像,上一次備份和下一次備份之間的數(shù)據(jù)怎么辦呢?只能通過binlog了,因此也需要備份binlog,而且最好也是存到遠(yuǎn)程上.

四. 發(fā)展

我們?cè)谑褂眠^程中,業(yè)務(wù)剛剛起步,有可能先單機(jī)模式,隨著業(yè)務(wù)的發(fā)展,我們就會(huì)擴(kuò)展到復(fù)制模式,隨著業(yè)務(wù)的再次壯大以及業(yè)務(wù)重要性的要求,就會(huì)開始引入集群模式了,保證數(shù)據(jù)真正的不丟失,即使一個(gè)節(jié)點(diǎn)出現(xiàn)宕機(jī),其他節(jié)點(diǎn)還有完整的數(shù)據(jù).

END

維易PHP培訓(xùn)學(xué)院每天發(fā)布《做了這么久的 DBA，你真的認(rèn)識(shí) MySQL 數(shù)據(jù)安全體系？》等實(shí)戰(zhàn)技能，PHP、MYSQL、LINUX、APP、JS,CSS全面培養(yǎng)人才。

轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/9613.html