上兩小節從實戰的角度介紹瞭如何搭建非同步複製和增強半同步複製，我想您肯定會有疑問，都是 MySQL的主從複製，它們之間究竟有啥不同呢。本小節我們一起來學習 MySQL 複製方式的對比，以及相對比較重要的複製引數。

1. 複製方式對比

除了非同步複製和增強半同步複製之外，介於它們之間其實還有一種複製方式，叫半同步複製，只是從MySQL 5.7開始，逐漸被增強半同步所替代。那麼這三種複製方式之間有什麼異同呢？請參考如下表格

1.1 非同步複製

在傳統的複製中，binlog 的複製是非同步的，啥時候複製到從庫，以及是否複製成功，MySQL 是不管的，存在丟失資料的風險：

1.2 半同步複製

半同步複製的執行步驟如下：

1. SQL 解析，會話T1(insert into t1 values(1000);)；
2. 儲存引擎處理；
3. 寫 binlog；
4. 提交至儲存；
5. 等待從庫成功接收 binlog 的返回訊號；
6. 反饋至客戶端。

這種同步方式的最大缺點是會出現丟失資料的風險，在步驟 4 之後，主庫出現會話 T2(select * from t1;)，可以讀取到 1000 這個值，但如果此時步驟 5 失敗，從庫是不能成功接收到 1000 這個值的，也就意味著表 t1 的 1000 在從庫是丟失的。

1.3 增強半同步複製

增強半同步複製的執行步驟如下：

1. SQL 解析，會話 T1(insert into t1 values(1000);)；
2. 儲存引擎處理；
3. 寫 binlog；
4. 等待從庫成功接收 binlog 的返回訊號；
5. 提交至儲存；
6. 反饋至客戶端。

增強半同步複製，號稱無損半同步複製。在步驟 3 之後，如果主庫出現會話 T2(select * from t1;)，是讀取不到 1000 這個值的。如果步驟 4 失敗，主從都一樣，不能成功提交 1000 這個值，確保資料的一致性。

2. 重要的複製引數

2.1 主庫

log-bin

binlog檔名字首，可以是全路徑，不可以動態修改

log-bin = /
 
mysql/3306/log

server-id

唯一區別 ID，同一個叢集內不可重複，從 5.6 開始可以動態修改

推薦使用ip+埠號，1013306

server-uuid

唯一區別 ID，同一個叢集內不可重複，從 5.6 開始可以動態修改：

32位的GUID，檔案路徑/mysql/3306/auto.cn

• log-bin-index

binlog索引檔案字首，也可以是全路徑，不可以動態修改

• binlog_format

binlog日誌格式：statement、row、mixed三種，可以動態修改

• binlog_cache_size

binlog寫入的buffer，推薦1M-4M就足夠，可以動態修改

• max_binlog_size

限制每個binlog的大小，預設是1G，推薦128M或256M，可以動態修改

• expire_logs_days

表示多少天后自動刪除binlog，可以動態修改

2.2 從庫

• server-id：唯一區別ID，同一個叢集內不可重複，從5.6開始可以動態修改，推薦使用ip+埠號，1013306；

• server-uuid：唯一區別ID，同一個叢集內不可重複，從5.6開始可以動態修改；32位的GUID，檔案路徑/mysql/3306/auto.cn；

• relay-log：relaylog檔名字首，可以是全路徑，不可以動態修改；複製程序io_thread讀取過來存到本地的日誌；

• relay-log-index：relaylog 索引檔案字首，也可以是全路徑，不可以動態修改；

• read-only：設定從庫是否只讀，但對super許可權的使用者不起作用，可以動態修改；

• log-slave-updates：將 master 傳輸過來的變更操作，再次記錄成本地 binlog，用於做二次複製，當做中繼分發節點，不可以動態修改；

• max_relay_log_size：限制每個 relaylog 的大小，推薦 128M 或 256M，可以動態修改。

3. 小結

本小節主要介紹了三種複製方式的異同點，以及一些比較重要的複製引數。

在實際應用場景中，MySQL 複製是使用最為廣泛的，用來提高系統可用性、擴充套件性的設計手段，也是MySQL 迅速流行的關鍵原因。一般來說，從 MySQL 5.7 開始，都推薦使用增強半同步的複製方式，基本可以實現資料 0 丟失。