前言：

MySQL 主從架構應該是最常用的一組架構了。從庫會實時同步主庫傳輸來的數據，一般從庫可以作為備用節點或作查詢使用。其實不只是主庫需要多關注，從庫有時候也要經常維護，本篇文章將會分享幾點從庫維護經驗，一起來學習吧。

1.主從復制建議采用 GTID 模式

GTID 即全局事務 ID（Global Transaction ID），GTID 實際上是由 server_uuid:transaction_id 組成的。其中 server_uuid 是一個 MySQL 實例的唯一標識， transaction_id 代表了該實例上已經提交的事務數量，并且隨著事務提交單調遞增，所以 GTID 能夠保證每個 MySQL 實例事務的執行（不會重復執行同一個事務，并且會補全沒有執行的事務）。

基于 GTID 的主從復制可以取代過去通過 binlog 文件偏移量定位復制位置的傳統方式。特別是對于一主多從的架構，借助GTID，在發生主備切換的情況下，MySQL 的其它 Slave 可以自動在新主上找到正確的復制位置，這大大簡化了復雜復制拓撲下集群的維護，也減少了人為設置復制位置發生誤操作的風險。另外，基于 GTID 的復制可以忽略已經執行過的事務,減少了數據發生不一致的風險。

2.建議從庫參數盡量和主庫保持一致

為保證主從庫數據一致性，建議從庫版本與主庫一致，相關參數盡量和主庫保持一致。比如字符集、默認存儲引擎、sql_mode 這類參數要設置一樣。特別是一些不可動態修改的參數，建議提前寫入配置文件并和主庫一致。

3.備份可在從庫端進行

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

4.從庫建議設為只讀

對于數據庫讀寫狀態，主要靠 read_only 全局參數來設定，默認情況下，數據庫是用于讀寫操作的，所以 read_only 參數是 0 或 false 狀態。這時候不論是本地用戶還是遠程訪問數據庫的用戶，只要有權限都可以進行讀寫操作。

為避免從庫發生手動更新操作，建議將從庫設置為只讀，即將 read_only 參數設置為1。read_only=1 只讀模式，不會影響從庫同步復制的功能，從庫仍然會讀取 master 上的日志，并且在 slave 端應用日志，保證主從數據庫同步一致。從庫設為只讀會限制不具有 super 權限的用戶進行數據修改操作，普通的應用用戶進行 insert 、 update 、 delete 等會產生數據變化的 DML 操作時，都會報出數據庫處于只讀模式。這樣能有效防止從庫發生更新操作。

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

5.注意從庫監控及主從延遲

從庫雖然不如主庫那么重要，但平時也要多關注從庫監控狀態，不要等到需要使用從庫時才發現從庫早已和主庫不一致了。除去一些基礎監控，從庫端要特別關注復制狀態及延遲狀態。

我們可以在從庫端執行 show slave status; 來查詢從庫狀態，其中主要關注的值有三個，分別為 Slave SQL Running ， Slave IO Running 和 Seconds Behind Master 。這三個值分別代表 SQL 線程運行狀態、 IO 線程運行狀態、從庫延遲秒數。只有當 Slave SQL Running ， Slave IO Running 為 yes ，然后 Seconds Behind Master 為0的時候，我們認為從庫運行正常。

總結：

本篇文章主要分享了個人關于從庫維護的幾點經驗，若有錯誤，還請指正。其他同學若有相關經驗或建議，也可以留言分享討論哦。

以上就是MySQL從庫維護經驗分享的詳細內容，更多關于MySQL從庫維護經驗的資料請關注腳本之家其它相關文章！