InnoDB 主從復制同步架構升級實戰：DRBD+Heartbeat 雙主多從

架構演進背景

原架構：一主多從 → 新架構：DRBD + Heartbeat 雙主多從。電商新項目上線，存儲引擎統一遷移至 InnoDB。

核心心得 5 條

1. 複制是異步的，有延遲

讀寫分離業務必須監控延遲（Seconds_Behind_Master），避免讀舊數據。

2. server-id 必須唯一

Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids

修改從庫 server-id 與主庫不同即可。

3. 從庫不必開啟 Binlog（除非雙主）

復制原理：從庫 I/O 線程 拉取主庫 Binlog → 寫入本地 Relay Log → SQL 線程 回放。從庫自身 Binlog 僅在「作為其他從庫的主庫」時需要。

4. 授權最小權限原則

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'192.168.1.%' IDENTIFIED BY 'pass';

僅授 REPLICATION SLAVE、REPLICATION CLIENT，內網亦嚴守。

5. 遵循標準流程，錯誤優先查網絡/權限

標準搭建流程成功率高，報錯多為防火牆、權限、server-id 衝突。

為什麼統一遷移至 InnoDB？

1. 電商涉及交易付款，OLTP 核心業務首選 InnoDB（事務、行鎖、外鍵）
2. DRBD 重啟過程頻繁讀表，MyISAM 極易損壞，InnoDB 崩潰安全

避坑實戰：1062 主鍵衝突

初期用 --single-transaction 導出主庫快照建從庫，頻發：

Error 'Duplicate entry ... for key PRIMARY' on query INSERT INTO lee_sessions ...

改用 --master-data=1 導出（自動記錄 Binlog 位置）：

mysqldump -uroot --quick --flush-logs --master-data=1 -p myproject > myproject.sql

此參數在導出文件頭部寫入 CHANGE MASTER TO MASTER_LOG_FILE='...', MASTER_LOG_POS=...;，確保從庫從精確位置開始復制，避免重放已執行事務導致主鍵衝突。

總結

InnoDB + 標準復制 + DRBD/Heartbeat 高可用 = 穩健電商架構基石。關鍵細節：server-id 唯一、從庫可關 Binlog、最小權限授權、--master-data 精確定位。