MySQL的主從複製原理詳細分析

2022-07-14 14:00:58

前言

在實際生產環境中，如果對mysql資料庫的讀和寫都在一臺資料庫伺服器中操作，無論是在安全性、高可用性，還是高並行等各個方面都是不能滿足實際需求的，一般要通過主從複製的方式來同步資料，再通過讀寫分離來提升資料庫的並行負載能力。

一、主從複製概念

主從複製是MySQL提供的基本的技術，主從複製的流程：binlog二進位制紀錄檔（除了查詢其他的更改相關的操作都會記錄在binlog裡面）、relay log紀錄檔和三個執行緒（master的一個執行緒和slave的兩個執行緒）。

主庫(master)對外提供資料的增刪改查服務，主庫中涉及到資料的修改都會寫在binlog從庫(slave)用來資料同步和資料備份，通過專門的執行緒從主庫裡面的binlog把主庫和資料、許可權、表結構相關的修改同步到從庫裡面，相當於是在主庫上做的所有修改都會通過都會通過主從複製機制體現在從庫上。

主從複製的好處：資料備份，我們甚至可以給它做一個熱備份，就是通過MySQL中介軟體mycat，可以實現容災，容災也體現了高可用。
容災：如果主庫掛了，由中介軟體代理mycat自動把服務的請求對映到從庫，由從庫繼續對外提供服務，體現出了高可用性（後端的服務允許一定的異常發生，但是後端的架構服務要可以容錯，把這些異常的錯誤處理掉，並對外重新提供正常的服務）

二、讀寫分離的概念

讀寫分離是基於主從複製來實現的。在實際的應用環境中，肯定是讀操作多，就像我們在電商平臺上去購買東西，可能看了100個也就買了一兩個。所以讀操作永遠比寫這種更新操作多很多。所以我們基於主從複製的讀寫分離設定，就是讓一個主庫專門用來做資料的修改，寫的時候專門在主庫上寫，主庫通過主從複製把資料的更改通過binlog同步到從庫上去，那麼其他的使用者端查詢的請求都會最終對映到從庫上去，而我們一個主庫帶上兩三個從庫，主庫專門用來做資料的更新（寫操作），從庫專門用來做讀操作這樣一來可以很好的分攤讀寫的壓力，不用全部都集中在主庫上，對於後端服務的並行處理能力有很大的提高，另外就是它的高可用容災，當主庫掛了以後，可以把指定的從庫變成主庫。

上圖中的binlog，即使我們沒有主從複製，也是會寫binlog的，只不過主從複製是通過binlog來實現的。

三、主庫和從庫

1. 主庫

主庫master伺服器建立一個binlog轉儲執行緒，將二進位制紀錄檔內容傳送到從伺服器

2. 從庫

從庫裡面專門有一個I/O執行緒專門讀取接收主庫傳送的內容，它會把主庫裡面發過來的binlog內容接收並寫到一個relay log裡面，中繼紀錄檔相當於做了一個緩衝，這樣 master 就不必等待 slave 執行完成才傳送下一個事件。並不是把主庫裡面的binlog內容讀過來直接就執行，這樣直接執行不好的地方就是主庫的binlog內容可能會很多，而從庫接收到binlog內容執行起來可能會很慢，導致從庫更新資料和主庫差距會越來越大。資料的複製可能比較落後。
從庫還會啟一個SQL執行緒，專門從中繼紀錄檔讀取相應的操作，所有的SQL都執行一遍，這樣就實現了從庫內容和主庫內容的同步

四、主從複製的流程

主從複製的流程：兩個紀錄檔（binlog二進位制紀錄檔和relay log紀錄檔）和三個執行緒（master的一個執行緒和slave的兩個執行緒）。

主庫的更新操作寫入binlog二進位制紀錄檔中（主庫需要開啟binlog開關）
master伺服器建立一個binlog轉儲執行緒，將二進位制紀錄檔內容傳送到從伺服器
slave機器執行START SLAVE命令會在從伺服器建立一個IO執行緒，接收master的binary log複製到其中繼紀錄檔（處於記憶體中，讀寫快）。首先slave開始一個工作執行緒（I/O執行緒），I/O執行緒會主動連線master ，然後主庫會開啟dump執行緒，dump執行緒從master的binlog中讀取事件並行送給slave的I/O執行緒，如果dump執行緒已經跟上master（主庫上的dump執行緒已經把binlog的內容發完了，而且主庫上binlog沒有產生更多的內容），dump執行緒會睡眠並等待binlog產生新的事件，slave的I/O執行緒接收的事件寫入中繼紀錄檔
slave的SQL執行緒處理該過程的最後一步，SQL執行緒從relay log中讀取事件，並執行其中的事件更新slave的資料，使其與master的資料同步。只要SQL執行緒與I/O執行緒保持一致，中繼紀錄檔通常會位於os快取中，所以中繼紀錄檔的開銷很小