blues001 ·MySQL 復(fù)制方式對比、復(fù)制參數(shù)
上兩小節(jié)從實戰(zhàn)的角度介紹了如何搭建異步復(fù)制和增強半同步復(fù)制，我想您肯定會有疑問，都是 MySQL的主從復(fù)制，它們之間究竟有啥不同呢。本小節(jié)我們一起來學(xué)習(xí) MySQL 復(fù)制方式的對比，以及相對比較重要的復(fù)制參數(shù)。
1. 復(fù)制方式對比
除了異步復(fù)制和增強半同步復(fù)制之外，介于它們之間其實還有一種復(fù)制方式，叫半同步復(fù)制，只是從MySQL 5.7開始，逐漸被增強半同步所替代。那么這三種復(fù)制方式之間有什么異同呢？請參考如下表格
| 異步復(fù)制 | 半同步復(fù)制 | 增強半同步復(fù)制 | |
|---|---|---|---|
| 部署難度 | 低 | 低 | 低 |
| 維護難度 | 低 | 中 | 中 |
| 數(shù)據(jù)丟失 | 中 | 中低 | 極低 |
| 性能影響 | 低 | 中 | 中 |
1.1 異步復(fù)制
在傳統(tǒng)的復(fù)制中，binlog 的復(fù)制是異步的，啥時候復(fù)制到從庫，以及是否復(fù)制成功，MySQL 是不管的，存在丟失數(shù)據(jù)的風(fēng)險：
1.2 半同步復(fù)制
半同步復(fù)制的執(zhí)行步驟如下：
- SQL 解析，會話T1(insert into t1 values(1000);)；
- 存儲引擎處理；
- 寫 binlog；
- 提交至存儲；
- 等待從庫成功接收 binlog 的返回信號；
- 反饋至客戶端。
這種同步方式的最大缺點是會出現(xiàn)丟失數(shù)據(jù)的風(fēng)險，在步驟 4 之后，主庫出現(xiàn)會話 T2(select * from t1;)，可以讀取到 1000 這個值，但如果此時步驟 5 失敗，從庫是不能成功接收到 1000 這個值的，也就意味著表 t1 的 1000 在從庫是丟失的。
1.3 增強半同步復(fù)制
增強半同步復(fù)制的執(zhí)行步驟如下：
- SQL 解析，會話 T1(insert into t1 values(1000);)；
- 存儲引擎處理；
- 寫 binlog；
- 等待從庫成功接收 binlog 的返回信號；
- 提交至存儲；
- 反饋至客戶端。
增強半同步復(fù)制，號稱無損半同步復(fù)制。在步驟 3 之后，如果主庫出現(xiàn)會話 T2(select * from t1;)，是讀取不到 1000 這個值的。如果步驟 4 失敗，主從都一樣，不能成功提交 1000 這個值，確保數(shù)據(jù)的一致性。
2. 重要的復(fù)制參數(shù)
2.1 主庫
log-bin
binlog文件名前綴，可以是全路徑，不可以動態(tài)修改
log-bin = /mysql/3306/log
server-id
唯一區(qū)別 ID，同一個集群內(nèi)不可重復(fù)，從 5.6 開始可以動態(tài)修改
推薦使用ip+端口號，1013306
server-uuid
唯一區(qū)別 ID，同一個集群內(nèi)不可重復(fù)，從 5.6 開始可以動態(tài)修改：
32位的GUID，文件路徑/mysql/3306/auto.cn
- log-bin-index
binlog索引文件前綴，也可以是全路徑，不可以動態(tài)修改
- binlog_format
binlog日志格式：statement、row、mixed三種，可以動態(tài)修改
- binlog_cache_size
binlog寫入的buffer，推薦1M-4M就足夠，可以動態(tài)修改
- max_binlog_size
限制每個binlog的大小，默認是1G，推薦128M或256M，可以動態(tài)修改
- expire_logs_days
表示多少天后自動刪除binlog，可以動態(tài)修改
2.2 從庫
-
server-id：唯一區(qū)別ID，同一個集群內(nèi)不可重復(fù)，從5.6開始可以動態(tài)修改，推薦使用ip+端口號，1013306；
-
server-uuid：唯一區(qū)別ID，同一個集群內(nèi)不可重復(fù)，從5.6開始可以動態(tài)修改；32位的GUID，文件路徑/mysql/3306/auto.cn；
-
relay-log：relaylog文件名前綴，可以是全路徑，不可以動態(tài)修改；復(fù)制進程io_thread讀取過來存到本地的日志；
-
relay-log-index：relaylog 索引文件前綴，也可以是全路徑，不可以動態(tài)修改；
-
read-only：設(shè)置從庫是否只讀，但對super權(quán)限的用戶不起作用，可以動態(tài)修改；
-
log-slave-updates：將 master 傳輸過來的變更操作，再次記錄成本地 binlog，用于做二次復(fù)制，當做中繼分發(fā)節(jié)點，不可以動態(tài)修改；
-
max_relay_log_size：限制每個 relaylog 的大小，推薦 128M 或 256M，可以動態(tài)修改。
3. 小結(jié)
本小節(jié)主要介紹了三種復(fù)制方式的異同點，以及一些比較重要的復(fù)制參數(shù)。
在實際應(yīng)用場景中，MySQL 復(fù)制是使用最為廣泛的，用來提高系統(tǒng)可用性、擴展性的設(shè)計手段，也是MySQL 迅速流行的關(guān)鍵原因。一般來說，從 MySQL 5.7 開始，都推薦使用增強半同步的復(fù)制方式，基本可以實現(xiàn)數(shù)據(jù) 0 丟失。
2025 imooc.com All Rights Reserved |