一、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 系統或簡單測試場景。
 recorder-core)
![[AI]大模型MCP快速入門及智能體執行模式介紹](http://pic.xiahunao.cn/[AI]大模型MCP快速入門及智能體執行模式介紹)
)
