看完這篇還不懂 MySQL 主從複製，可以回家躺平了～

過程

工作過程

MySQL 的主從複製工作過程大致如下：

1. 從庫生成兩個執行緒，一個 I/O 執行緒，一個 SQL 執行緒；

2. I/O 執行緒去請求主庫的 binlog，並將得到的 binlog 日誌寫到 relay log(中繼日誌) 檔案中；

3. 主庫會生成一個 log dump 執行緒，用來給從庫 I/O 執行緒傳 binlog；

4. SQL 執行緒會讀取 relay log 檔案中的日誌，並解析成具體操作，來實現主從的操作一致，而最終資料一致；

請求流程

MySQL 建立請求的主從的詳細流程如下：

1. 當從伺服器連線主伺服器時，主伺服器會建立一個 log dump 執行緒，用於傳送 binlog 的內容。在讀取 binlog 的內容的操作中，會物件主節點上的 binlog 加鎖，當讀取完成併傳送給從伺服器後解鎖。

2. 當從節點上執行 start slave 命令之後，從節點會建立一個 IO 執行緒用來連線主節點，請求主庫中更新 binlog。IO 執行緒接收主節點 binlog dump 程式發來的更新之後，儲存到 relay-log 中。

3. 從節點 SQL 執行緒負責讀取 realy-log 中的內容，解析成具體的操作執行，最終保證主從資料的一致性。

非同步複製

一個主庫，一個或多個從庫，資料非同步同步到從庫。

這種模式下，主節點不會主動推送資料到從節點，主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端，並不關心從庫是否已經接收並處理。

這樣就會有一個問題，主節點如果崩潰掉了，此時主節點上已經提交的事務可能並沒有傳到從節點上，如果此時，強行將從提升為主，可能導致新主節點上的資料不完整。

同步複製

在 MySQL cluster 中特有的複製方式。

當主庫執行完一個事務，然後所有的從庫都複製了該事務並成功執行完才返回成功資訊給客戶端。

因為需要等待所有從庫執行完該事務才能返回成功資訊，所以全同步複製的效能必然會收到嚴重的影響。

半同步複製

在非同步複製的基礎上，確保任何一個主庫上的事物在提交之前至少有一個從庫已經收到該事物並日志記錄下來。

介於非同步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是立刻返回給客戶端，而是等待至少一個從庫接收到並寫到 relay log 中才返回成功資訊給客戶端(只能保證主庫的 Binlog 至少傳輸到了一個從節點上)，否則需要等待直到超時時間然後切換成非同步模式再提交。

相對於非同步複製，半同步複製提高了資料的安全性，一定程度的保證了資料能成功備份到從庫，同時它也造成了一定程度的延遲，但是比全同步模式延遲要低，這個延遲最少是一個 TCP/IP 往返的時間。所以，半同步複製最好在低延時的網路中使用。

半同步模式不是 MySQL 內建的，從 MySQL 5.5 開始整合，需要 master 和 slave 安裝外掛開啟半同步模式。

延遲複製

在非同步複製的基礎上，人為設定主庫和從庫的資料同步延遲時間，即保證資料延遲至少是這個引數。

# 如果在雙主複製結構中沒有設定ID的話就會導致迴圈同步問題
server_id=1

# 即日誌中記錄的是語句還是行更新或者是混合
binlog_format=mixed

# 在進行n次事務提交以後，Mysql將執行一次fsync的磁碟同步指令。將緩衝區資料重新整理到磁碟。
# 為0的話由Mysql自己控制頻率。
sync_binlog=n

# 為0的話，log buffer將每秒一次地寫入log file中並且重新整理到磁碟。
# mysqld程式崩潰會丟失一秒內的所有事務。
# 為1的話，每次事務log buffer會寫入log file並重新整理到磁碟。（較為安全）
# 在崩潰的時候,僅會丟失一個事務。
# 為2的話，每次事務log buffer會寫入log file，但一秒一次重新整理到磁碟
innodb_flush_logs_at_trx_commit=0

# 阻止從庫崩潰後自動啟動複製，給一些時間來修復可能的問題，
# 崩潰後再自動複製可能會導致更多的問題。並且本身就是不一致的
skip_slave_start=1 

# 是否將從庫同步的事件也記錄到從庫自身的bin-log中
# 允許備庫將重放的事件也記錄到自身的二進位制日誌中去，可以將備庫當做另外一臺主庫的從庫
log_slave_update 

# 日誌過期刪除時間，延遲嚴重的話會導致日誌檔案佔用磁碟
expire_logs_days=7

注意事項

MySQL 需要注意以下事項：

• MySQL 主從複製是 MySQL 高可用性，高效能（負載均衡）的基礎；

• 簡單，靈活，部署方式多樣，可以根據不同業務場景部署不同複製結構；

• 複製過程中應該時刻監控複製狀態，複製出錯或延時可能給系統造成影響；

• MySQL 主從複製目前也存在一些問題，可以根據需要部署複製增強功能。

MySQL 主從複製叢集功能使得 MySQL 資料庫支援大規模高併發讀寫成為可能，同時有效地保護了物理伺服器當機場景的資料備份。

橫向擴充套件

將工作負載分發到各 Slave 節點上，從而提高系統效能。

在這個場景下，所有的寫(write)和更新(update)操作都在 Master 節點上完成；所有的讀( read)操作都在 Slave 節點上完成。透過增加更多的 Slave 節點，便能提高系統的讀取速度。

資料安全

資料從 Master 節點複製到 Slave 節點上，在 Slave 節點上可以暫停複製程式。可以在 Slave 節點上備份與 Master 節點對應的資料，而不用影響 Master 節點的執行。

資料分析

實時資料可以在 Master 節點上建立，而分析這些資料可以在 Slave 節點上進行，並且不會對 Master 節點的效能產生影響。

遠距離資料分佈

可以利用複製在遠端主機上建立一份本地資料的副本，而不用持久的與Master節點連線。

拆分訪問

可以把幾個不同的從伺服器，根據公司的業務進行拆分。透過拆分可以幫助減輕主伺服器的壓力，還可以使資料庫對外部使用者瀏覽、內部使用者業務處理及 DBA 人員的備份等互不影響。