一、MySQL主從復制基礎
1. 核心概念
- 定義:
MySQL主從復制是將主庫(Source/Master)的數據變更同步到一個或多個從庫(Replica/Slave)的機制,默認采用異步復制,支持全庫、指定庫或表的同步。
- 角色:
- 主庫:負責處理寫請求,記錄二進制日志(Binlog)。
- 從庫:通過讀取主庫Binlog并回放(Relay Log)實現數據同步,支持讀請求分擔。
2. 核心優勢
- 高可用性:通過多從庫部署提升容災能力,主庫故障時可手動/自動切換至從庫。
- 讀寫分離:從庫承擔讀請求,緩解主庫壓力,提升整體吞吐量。
- 異地災備:從庫部署至異地機房,降低地域級故障風險。
3. 復制類型
- 異步復制:主庫提交事務后立即返回客戶端,無需等待從庫確認,可能存在延遲和數據丟失風險。
- 半同步復制:主庫等待至少一個從庫確認接收Binlog后再提交事務,提升數據可靠性,但增加響應延遲。
- 延遲復制:從庫故意落后主庫指定時間,用于數據誤操作恢復(如誤刪表)。
二、異步復制原理與配置
1. 核心流程(基于Binlog位點)
- 主庫生成Binlog:
主庫執行寫操作時,將變更記錄到Binlog文件(如mysql-bin.000001
)。
- 從庫拉取Binlog:
從庫的I/O線程通過CHANGE MASTER TO
指定主庫地址、Binlog文件名(如mysql-bin.000001
)和起始位置(Position),請求同步數據。
- 主庫推送Binlog:
主庫的Dump線程根據從庫請求的位點推送Binlog數據。
- 從庫寫入中繼日志(Relay Log):
從庫接收Binlog并寫入本地Relay Log,由SQL線程解析并回放,更新本地數據。
2. 關鍵配置步驟(示例)
主庫配置:
# custom.cnf
[mysqld]
server-id=10 # 唯一標識主庫
log-bin=mysql-bin # 啟用Binlog
binlog-format=ROW # 推薦使用ROW格式,記錄行級變更
從庫配置:
[mysqld]
server-id=11 # 唯一標識從庫
relay-log=relay-bin # 中繼日志路徑
read-only=ON # 從庫設置為只讀(避免誤寫)
主從連接配置(從庫執行):
-- MySQL 8.0.23前使用CHANGE MASTER TO
CHANGE MASTER TO MASTER_HOST='主庫IP',MASTER_PORT=3306,MASTER_USER='復制用戶',MASTER_PASSWORD='密碼',MASTER_LOG_FILE='mysql-bin.000001', -- 主庫當前Binlog文件MASTER_LOG_POS=1234; -- 主庫當前Binlog位置-- MySQL 8.0.23+使用CHANGE REPLICATION SOURCE TO
CHANGE REPLICATION SOURCE TO SOURCE_HOST='主庫IP',SOURCE_PORT=3306,SOURCE_USER='復制用戶',SOURCE_PASSWORD='密碼',SOURCE_LOG_FILE='mysql-bin.000001',SOURCE_LOG_POS=1234;START REPLICA; -- 啟動從庫復制線程
3. 狀態驗證
-- 主庫查看Binlog狀態
SHOW MASTER STATUS;-- 從庫查看復制狀態(關鍵字段)
SHOW REPLICA STATUS \G
# 重點關注:
# Replica_IO_Running: Yes -- I/O線程運行正常
# Replica_SQL_Running: Yes -- SQL線程運行正常
# Seconds_Behind_Master: 0 -- 復制延遲(0表示無延遲)
三、半同步復制:提升數據可靠性
1. 核心原理
- 主庫在提交事務前,等待至少一個從庫確認已接收并寫入Relay Log。
- 若從庫超時未響應,主庫退化為異步復制;從庫恢復后自動切回半同步。
2. 關鍵配置
主庫啟用半同步插件:
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET GLOBAL rpl_semi_sync_source_enabled=ON;
從庫啟用半同步插件:
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET GLOBAL rpl_semi_sync_replica_enabled=ON;
核心參數:
rpl_semi_sync_source_wait_for_replica_count
:主庫等待至少N個從庫確認(默認1)。rpl_semi_sync_source_timeout
:等待超時時間(毫秒,默認10000)。
四、基于GTID的復制:自動化位點管理
1. GTID核心優勢
- 全局唯一事務ID:每個事務在主庫生成唯一GTID(格式:
server_uuid:transaction_id
),避免Binlog位點手動管理。 - 自動定位同步起點:從庫通過
MASTER_AUTO_POSITION=1
自動獲取主庫最新事務,無需指定Binlog文件名和位置。 - 一致性保障:確保每個事務在主從庫僅執行一次,避免重復或遺漏。
2. 配置要點
主從庫啟用GTID:
[mysqld]
gtid_mode=ON # 啟用GTID模式
enforce_gtid_consistency=ON # 強制GTID一致性(避免非事務語句破壞一致性)
從庫配置(自動定位):
CHANGE REPLICATION SOURCE TO SOURCE_HOST='主庫IP',SOURCE_PORT=3306,SOURCE_USER='復制用戶',SOURCE_PASSWORD='密碼',SOURCE_AUTO_POSITION=1; # 關鍵:啟用自動位點管理START REPLICA;
3. 主從切換實戰
- 模擬主庫宕機:停止主庫服務。
- 提升從庫為新主庫:
-- 在目標從庫執行(如replica1)
STOP REPLICA;
RESET MASTER; -- 清除原有復制配置,成為主庫
- 其他從庫指向新主庫:
CHANGE REPLICATION SOURCE TO SOURCE_HOST='新主庫IP',SOURCE_AUTO_POSITION=1;
START REPLICA;
五、主從復制痛點與解決方案
1. 傳統Binlog位點復制的痛點
- 手動管理復雜:首次配置或故障恢復時需手動指定Binlog文件名和位置,易出錯。
- 單點故障風險:主庫宕機后,從庫需人工選擇新主庫并配置位點,耗時且可能丟失數據。
2. GTID的解決方案
- 自動化位點管理:通過
SOURCE_AUTO_POSITION
自動同步最新事務,無需人工干預。 - 快速故障切換:從庫基于GTID集合差集自動追趕數據,減少切換時間。
六、總結:復制模式對比
維度 | 異步復制(Binlog位點) | 半同步復制 | GTID復制 |
數據可靠性 | 低(可能丟數據) | 中(至少1從庫確認) | 高(事務唯一且有序) |
配置復雜度 | 高(手動管理位點) | 中(需配置插件和參數) | 低(自動位點管理) |
故障恢復 | 慢(人工配置位點) | 中(需手動切換主庫) | 快(自動同步差集事務) |
適用場景 | 非核心業務、低延遲要求 | 金融類中等可靠性場景 | 高可用集群、頻繁主從切換場景 |
建議:生產環境優先使用GTID+半同步復制組合,平衡可靠性與性能;傳統Binlog位點復制僅用于 legacy 系統或簡單測試場景。