MySQL 復制方式對比、復制參數

上兩小節從實戰的角度介紹了如何搭建異步復制和增強半同步復制，我想您肯定會有疑問，都是 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 丟失。