MySQL從庫維護(hù)經(jīng)驗(yàn)分享

前言：

MySQL 主從架構(gòu)應(yīng)該是最常用的一組架構(gòu)了。從庫會(huì)實(shí)時(shí)同步主庫傳輸來的數(shù)據(jù)，一般從庫可以作為備用節(jié)點(diǎn)或作查詢使用。其實(shí)不只是主庫需要多關(guān)注，從庫有時(shí)候也要經(jīng)常維護(hù)，本篇文章將會(huì)分享幾點(diǎn)從庫維護(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)方式。特別是對于一主多從的架構(gòu)，借助GTID，在發(fā)生主備切換的情況下，MySQL 的其它 Slave 可以自動(dòng)在新主上找到正確的復(fù)制位置，這大大簡化了復(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.建議從庫參數(shù)盡量和主庫保持一致

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

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

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

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

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

為避免從庫發(fā)生手動(dòng)更新操作，建議將從庫設(shè)置為只讀，即將 read_only 參數(shù)設(shè)置為1。read_only=1 只讀模式，不會(huì)影響從庫同步復(fù)制的功能，從庫仍然會(huì)讀取 master 上的日志，并且在 slave 端應(yīng)用日志，保證主從數(shù)據(jù)庫同步一致。從庫設(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ù)庫處于只讀模式。這樣能有效防止從庫發(fā)生更新操作。

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

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

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

我們可以在從庫端執(zhí)行 show slave status; 來查詢從庫狀態(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)、從庫延遲秒數(shù)。只有當(dāng) Slave SQL Running ， Slave IO Running 為 yes ，然后 Seconds Behind Master 為0的時(shí)候，我們認(rèn)為從庫運(yùn)行正常。

總結(jié)：

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

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