mysql 主從備份原理

mysql主從複制用途

主從部署必要條件：

在備庫 B 上通過 change master 指令，設定主庫 A 的 IP、端口、使用者名、密碼，以及要從哪個位置開始請求 binlog，這個位置包含檔案名和日志偏移量，主庫驗證從庫，交給主庫IO線程負責資料傳輸;
在備庫 B 上執行 start slave 指令，這時候備庫會啟動兩個線程，就是圖中的 io_thread 和 sql_thread。其中 io_thread 負責與主庫建立連接配接，主庫 A 校驗完使用者名、密碼後，開始按照備庫 B master.info裡傳過來的位置，從本地讀取 binlog，将binlog檔案資訊，偏移量和binlog檔案名等發給 B
從庫接收到資訊後，将binlog資訊儲存到relay-bin中，同時更新master.info的偏移量和binlog檔案名
從庫的SQL線程不斷的讀取relay-bin的資訊，同時将讀到的偏移量和檔案名寫道relay-log.info檔案，binlog資訊寫進自己的資料庫，一次同步操作完成。
完成上次同步後，從庫IO線程不斷的向主庫IO線程要binlog資訊
從庫如果也要做主庫，也要打開log_bin 和log-slave-update參數

在狀态 1 中，用戶端的讀寫都直接通路節點 A，而節點 B 是 A 的備庫，隻是将 A 的更新都同步過來，到本地執行。這樣可以保持節點 B 和 A 的資料是相同的。當需要切換的時候，就切成狀态 2。這時候用戶端讀寫通路的都是節點 B，而節點 A 是 B 的備庫。

在狀态 1 中，雖然節點 B 沒有被直接通路，但是我依然建議你把節點 B（也就是備庫）設定成隻讀（readonly）模式。這樣做，有以下幾個考慮：

有同學想，我把從庫設定成隻讀了，還怎麼跟主庫保持同步更新呢？這個問題，你不用擔心。因為 readonly 設定對超級 (super) 權限使用者是無效的，而用于同步更新的線程，就擁有超級權限。

更新請求對 IOPS 的壓力，在主庫和從庫上是無差别的，從的機器性能比主的機器差時，當從庫主機上的多個從庫都在争搶資源的時候，就可能會導緻主從延遲

我們作了主從讀寫分離，開發寫的代碼執行大量讀的查詢時，對從壓力較大，導緻從的cpu或者記憶體占用很高，導緻主從延遲，可以一主多從來解決，但是不宜過多，一般3-5個從，過多的從也會導緻主從延遲同步

主和從的機器不在同一台機房，網絡傳輸資料較慢導緻的主從延遲

主庫上必須等事務執行完成才會寫入 binlog，再傳給備庫。是以，如果一個主庫上的語句執行 10 分鐘，那這個事務很可能就會導緻從庫延遲 10 分鐘