MySQL 主從複製原理

引言

MySQL 主從複製原理是至關基礎的知識，好久沒有接觸過 MySQL 主從複製了，由於我這邊負責的業務暫時沒用使用 MySQL 主從複製。
既然有些忘記了，如今我從新複習記錄下。

MySQL 主從複製介紹

MySQL 的主從複製是一個異步的複製過程（但通常狀況下感受是實時同步的），
數據庫數據從一個 MySQL 數據庫（咱們稱之爲 Master）複製到另外一個 MySQL 數據庫（咱們稱之爲 Slave）。
在 Master 與 Slave 之間實現整個主從複製的過程是由三個線程參與完成的。
其中有兩個線程（SQL 線程和 IO 線程）在 Slave 端，另一個線程（IO 線程）在 Master 端。（來自 MySQL 幫助文檔）

MySQL Replication 複製過程

1. Slave 服務器上執行start slave，開啓主從複製開關。
2. 此時，Slave 服務器上的 IO 線程會經過 Master 服務器上受權的有複製權限的用戶請求鏈接 Master 服務器，
   並請求從指定 binlog 日誌文件的指定位置以後發送 binlog 日誌內容。
   （日誌文件名和位置就是在配置主從複製任務時執行change master命令時指定的）
3. Master 服務器接收到來自 Slave 服務器的 IO 線程的請求後， Master 服務器上的 IO 線程根據 Slave
   服務器的 IO 線程請求的信息， 讀取指定 binlog 日誌文件指定位置以後的 binlog 日誌信息，而後返回給 Slave 端的
   IO 線程。 返回的信息中除了 binlog 日誌內容外， 還有本次返回日誌內容後在 Master 服務器端的新的 binlog
   文件名以及在 binlog 中的下一個指定更新位置。
4. 當 Slave 服務器的 IO 線程獲取來自 Master 服務器上 IO 線程發送的日誌內容及日誌文件和位置點後， 將 binlog
   日誌內容依次寫入到 Slave 端自身的 relay log（即中繼日誌）文件（mysql-relay-bin.xxxxxx）的最末端，
   並將新的 binlog 文件名和位置記錄到 master-info 文件中， 以便下一次讀取 Master 端新 binlog 日誌時，
   能告訴 Master 服務器須要重新 binlog 日誌的哪一個文件哪一個位置開始請求新的 binlog 日誌內容。
5. Slave 服務器端的 SQL 線程會實時檢測本地 relay log 中新增長的日誌內容， 而後及時的把 relay log
   文件中的內容解析成在 Master 端曾經執行的 SQL 語句的內容， 並在自身 Slave 服務器上按語句的順序執行應用這些 SQL
   語句，應用完畢後清理應用過的日誌。
6. 通過了上面的過程，就能夠確保在 Master 端和 Slave 端執行了一樣的 SQL 語句。 當複製狀態正常的狀況下，Master
   端和 Slave 端的數據是徹底同樣的。