前言：

MySQL 主從架構(gòu)應(yīng)該是最常用的一組架構(gòu)了。從庫(kù)會(huì)實(shí)時(shí)同步主庫(kù)傳輸來的數(shù)據(jù)，一般從庫(kù)可以作為備用節(jié)點(diǎn)或作查詢使用。其實(shí)不只是主庫(kù)需要多關(guān)注，從庫(kù)有時(shí)候也要經(jīng)常維護(hù)，本篇文章將會(huì)分享幾點(diǎn)從庫(kù)維護(hù)經(jīng)驗(yàn)，一起來學(xué)習(xí)吧。

1.主從復(fù)制建議采用 GTID 模式

GTID 即全局事務(wù) ID（Global Transaction ID），GTID 實(shí)際上是由 server_uuid:transaction_id 組成的。其中 server_uuid 是一個(gè) MySQL 實(shí)例的唯一標(biāo)識(shí)， transaction_id 代表了該實(shí)例上已經(jīng)提交的事務(wù)數(shù)量，并且隨著事務(wù)提交單調(diào)遞增，所以 GTID 能夠保證每個(gè) MySQL 實(shí)例事務(wù)的執(zhí)行（不會(huì)重復(fù)執(zhí)行同一個(gè)事務(wù)，并且會(huì)補(bǔ)全沒有執(zhí)行的事務(wù)）。

基于 GTID 的主從復(fù)制可以取代過去通過 binlog 文件偏移量定位復(fù)制位置的傳統(tǒng)方式。特別是對(duì)于一主多從的架構(gòu)，借助GTID，在發(fā)生主備切換的情況下，MySQL 的其它 Slave 可以自動(dòng)在新主上找到正確的復(fù)制位置，這大大簡(jiǎn)化了復(fù)雜復(fù)制拓?fù)湎录旱木S護(hù)，也減少了人為設(shè)置復(fù)制位置發(fā)生誤操作的風(fēng)險(xiǎn)。另外，基于 GTID 的復(fù)制可以忽略已經(jīng)執(zhí)行過的事務(wù),減少了數(shù)據(jù)發(fā)生不一致的風(fēng)險(xiǎn)。

2.建議從庫(kù)參數(shù)盡量和主庫(kù)保持一致

為保證主從庫(kù)數(shù)據(jù)一致性，建議從庫(kù)版本與主庫(kù)一致，相關(guān)參數(shù)盡量和主庫(kù)保持一致。比如字符集、默認(rèn)存儲(chǔ)引擎、sql_mode 這類參數(shù)要設(shè)置一樣。特別是一些不可動(dòng)態(tài)修改的參數(shù)，建議提前寫入配置文件并和主庫(kù)一致。

3.備份可在從庫(kù)端進(jìn)行

MySQL 全量備份會(huì)對(duì)服務(wù)器造成一定壓力，有時(shí)也會(huì)短暫持有全局鎖。特別是數(shù)據(jù)量大，業(yè)務(wù)繁忙的數(shù)據(jù)庫(kù)，全量備份可能會(huì)對(duì)業(yè)務(wù)產(chǎn)生影響。建議將備份腳本部署在從庫(kù)服務(wù)器上，全量備份可以放在從庫(kù)端進(jìn)行，這樣能減少備份過程中對(duì)于主庫(kù)業(yè)務(wù)的影響。

4.從庫(kù)建議設(shè)為只讀

對(duì)于數(shù)據(jù)庫(kù)讀寫狀態(tài)，主要靠 read_only 全局參數(shù)來設(shè)定，默認(rèn)情況下，數(shù)據(jù)庫(kù)是用于讀寫操作的，所以 read_only 參數(shù)是 0 或 false 狀態(tài)。這時(shí)候不論是本地用戶還是遠(yuǎn)程訪問數(shù)據(jù)庫(kù)的用戶，只要有權(quán)限都可以進(jìn)行讀寫操作。

為避免從庫(kù)發(fā)生手動(dòng)更新操作，建議將從庫(kù)設(shè)置為只讀，即將 read_only 參數(shù)設(shè)置為1。read_only=1 只讀模式，不會(huì)影響從庫(kù)同步復(fù)制的功能，從庫(kù)仍然會(huì)讀取 master 上的日志，并且在 slave 端應(yīng)用日志，保證主從數(shù)據(jù)庫(kù)同步一致。從庫(kù)設(shè)為只讀會(huì)限制不具有 super 權(quán)限的用戶進(jìn)行數(shù)據(jù)修改操作，普通的應(yīng)用用戶進(jìn)行 insert 、 update 、 delete 等會(huì)產(chǎn)生數(shù)據(jù)變化的 DML 操作時(shí)，都會(huì)報(bào)出數(shù)據(jù)庫(kù)處于只讀模式。這樣能有效防止從庫(kù)發(fā)生更新操作。

此外，有條件的情況下，從庫(kù)可以承擔(dān)部分查詢工作。比如一些報(bào)表聚合分析查詢或者外部服務(wù)查詢都可以配置從庫(kù)查詢，減少對(duì)主庫(kù)的壓力。

5.注意從庫(kù)監(jiān)控及主從延遲

從庫(kù)雖然不如主庫(kù)那么重要，但平時(shí)也要多關(guān)注從庫(kù)監(jiān)控狀態(tài)，不要等到需要使用從庫(kù)時(shí)才發(fā)現(xiàn)從庫(kù)早已和主庫(kù)不一致了。除去一些基礎(chǔ)監(jiān)控，從庫(kù)端要特別關(guān)注復(fù)制狀態(tài)及延遲狀態(tài)。

我們可以在從庫(kù)端執(zhí)行 show slave status; 來查詢從庫(kù)狀態(tài)，其中主要關(guān)注的值有三個(gè)，分別為 Slave SQL Running ， Slave IO Running 和 Seconds Behind Master 。這三個(gè)值分別代表 SQL 線程運(yùn)行狀態(tài)、 IO 線程運(yùn)行狀態(tài)、從庫(kù)延遲秒數(shù)。只有當(dāng) Slave SQL Running ， Slave IO Running 為 yes ，然后 Seconds Behind Master 為0的時(shí)候，我們認(rèn)為從庫(kù)運(yùn)行正常。

總結(jié)：

本篇文章主要分享了個(gè)人關(guān)于從庫(kù)維護(hù)的幾點(diǎn)經(jīng)驗(yàn)，若有錯(cuò)誤，還請(qǐng)指正。其他同學(xué)若有相關(guān)經(jīng)驗(yàn)或建議，也可以留言分享討論哦。

以上就是MySQL從庫(kù)維護(hù)經(jīng)驗(yàn)分享的詳細(xì)內(nèi)容，更多關(guān)于MySQL從庫(kù)維護(hù)經(jīng)驗(yàn)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！