前言

隨著業務量增長，單一 MySQL 實例往往難以應對高並發讀寫壓力。主從架構作為 MySQL 原生高可用與讀寫分離方案，憑藉成熟的復制機制，成為中小型系統擴展的首選。本文將系統梳理主從架構原理、優缺點，並提供生產級配置步驟與驗證方法。

一、主從架構核心原理

MySQL 主從架構包含一個主庫與一個或多個從庫。主庫負責處理所有寫入請求並開啟二進制日誌，從庫通過 I/O 線程拉取主庫 Binlog，再由 SQL 線程重放實現數據同步。為防止數據分歧，從庫通常設置 read_only=ON 僅提供查詢服務。

核心優勢

• 高可用性：主庫故障時可快速提升從庫為新主，縮短 RTO
• 讀寫分離：將報表、分析類查詢分流至從庫，降低主庫負載
• 備份無感：在從庫執行 mysqldump 或物理備份，避免主庫鎖表影響業務

固有局限

MySQL 預設採用異步復制，主從間存在毫秒到秒級延遲。對強一致性要求極高的業務（如扣款、庫存），仍需路由至主庫讀取，或升級為半同步/Group Replication 架構。

二、生產環境部署步驟（以 5.7 為例）

1. 環境準備

角色	IP	Server ID	備註
Master	192.168.1.100	1	讀寫節點
Slave	192.168.1.101	2	唯讀節點，可多台

確保兩節點：
① 系統版本、MySQL 版本一致
② 關閉防火牆或放行 3306 端口
③ 關閉 SELinux
④ 時間同步（NTP）

2. 主庫配置 /etc/my.cnf

[mysqld]
server-id=1
log-bin=mysql-bin
binlog-format=ROW
binlog-do-db=orders          # 僅同步業務庫
binlog-ignore-db=mysql       # 忽略系統庫
sync_binlog=1                # 高可靠，防丟事務
innodb_flush_log_at_trx_commit=1
gtid_mode=ON                 # 推薦啟用 GTID
enforce-gtid-consistency=ON

修改後執行 systemctl restart mysqld 生效。

3. 建立復制賬號

CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'StrongPass#2024';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;

4. 獲取同步起點

-- 主庫執行
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
-- 記下 File 與 Position，如：mysql-bin.000001, 154
UNLOCK TABLES;

5. 數據基線同步

推薦使用 mysqldump --single-transaction --master-data=2 --all-databases 邏輯備份，或 Percona XtraBackup 物理備份（大數據量首選）。將備份文件傳至從庫並導入：

scp backup.sql root@192.168.1.101:/tmp/
mysql -uroot -p < /tmp/backup.sql

6. 從庫配置 /etc/my.cnf

[mysqld]
server-id=2
relay-log=relay-bin
read_only=ON
replicate-do-db=orders
replicate-ignore-db=mysql,test,information_schema,performance_schema
gtid_mode=ON
enforce-gtid-consistency=ON

重啟後配置同步源：

CHANGE MASTER TO
  MASTER_HOST='192.168.1.100',
  MASTER_USER='repl',
  MASTER_PASSWORD='StrongPass#2024',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154,
  MASTER_AUTO_POSITION=1;   -- 若啟用 GTID
START SLAVE;

7. 狀態驗證

SHOW SLAVE STATUS\G
-- 關鍵指標均為 Yes 即正常
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

三、常見坑點與最佳實踐

1. Server ID 唯一：集群內所有節點（含備用節點）必須不同
2. Binlog 格式：生產環境強制 ROW，避免 Statement 模式下非確定性函數導致不一致
3. 延遲監控：接入 Prometheus + Grafana 監控 Seconds_Behind_Master，設置告警閾值
4. 故障切換：引入 MHA、Orchestrator 或 ProxySQL 實現自動故障轉移
5. 多從庫擴展：新增從庫只需修改 Server ID、複製基線數據、配置 CHANGE MASTER

四、總結

主從架構雖非強一致，但以極低成本解決了讀擴展、備份隔離、基礎高可用三大痛點。掌握上述標準化部署流程，配合監控與自動化運維工具，即可支撐千萬級日活業務。後續可演進至 MGR、InnoDB Cluster 獲得金融級強一致能力。