MySQL 的主從復制基于 binlog 實現(xiàn)，其主要過程如下：

圖片

1. 從服務器在開啟主從復制后，將會創(chuàng)建兩個線程：I/O 線程與 SQL 線程。
2. 從服務器的 I/O 線程會嘗試與主服務器建立連接，主服務器中則有一個專門與從服務器的 I/O 線程進行交互的 binlog dump 線程。
3. 從服務器的 I/O 線程會向主服務器的 dump 線程指明其接收 binlog 的起始位置。
4. 在主服務器的更新過程中，更改記錄會被保存到其 binlog 中，依據(jù)不同的 binlog 格式，記錄的內(nèi)容可能有所不同。
5. 當 dump 線程檢測到 binlog 發(fā)生變化時，將從指定位置開始讀取內(nèi)容，并由從服務器的 I/O 線程將其拉取過來。

這里需要注意的是，盡管某些資料提到主服務器向從服務器推送數(shù)據(jù)，實際上，過程是從服務器主動向主服務器拉取的。（https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html）

拉的模式，從庫可以自行管理同步進度和處理延遲。

• 從服務器的 I/O 線程在接收到通知事件后，會將內(nèi)容保存至 relay log 中。
• 從服務器的 SQL 線程則會不斷讀取自身的 relay log，將內(nèi)容解析為具體操作，并將其寫入數(shù)據(jù)表中。

復制方式

MySQL 目前支持多種復制方式，包括全同步復制、異步復制和半同步復制。

異步復制：這是 MySQL 的默認復制方式。在異步復制中，主庫在執(zhí)行完事務后會立即向客戶端返回，無需關心從庫是否完成該事務的執(zhí)行。這種方式可能導致問題：當主庫發(fā)生故障時，盡管事務已執(zhí)行完畢，但數(shù)據(jù)可能尚未同步至從庫，導致從庫在升級為主庫時丟失此次事務的變更內(nèi)容。

全同步復制：在全同步復制模式下，主庫在完成事務后，會等待所有從庫完成數(shù)據(jù)復制后，才向客戶端反饋。這種方式雖然提高了安全性，但性能較差，尤其在從庫數(shù)量較多時，整個過程將顯得更加漫長。

半同步復制：半同步復制介于全同步與異步之間。當主庫執(zhí)行完事務后，它不會立即反饋給客戶端，而是等待至少一個從庫完成接收事件后再反饋。在這一方案中，主庫會在事務提交的兩個階段完成后，等待從庫接收到 binlog 后，再返回成功。

在上面這篇中所繪制的圖示中，如果將半同步復制的過程也納入其中，那么圖示將會變?yōu)椋?/p>

圖片