前言：

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的時候，我們認為從庫執行正常。

總結：

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