本文 AI 產出，尚未審核
MySQL 高可用架構 – 常見高可用架構介紹
簡介
在現代資訊系統裡，資料是最核心的資產。當服務需要 24/7 全天候運作時，單一 MySQL 伺服器的故障就可能造成整個業務中斷，帶來巨大的損失與信任危機。為了降低單點故障 (Single Point of Failure, SPOF)、提升系統的可用性與容錯能力，我們必須在 MySQL 之上建置「高可用」(High Availability, HA) 架構。
本篇將以 易懂的語言 逐一說明目前最常見的 MySQL 高可用方案，包含其原理、部署要點與實務操作範例，協助 初學者到中級開發者 能快速上手、在自己的專案中落實高可用設計。
核心概念
1. 主從複製 (Master‑Slave Replication)
最傳統的 HA 方式是將寫入操作集中在「主」 (master) 節點，然後把二進位日誌 (binary log) 複製到一或多個「從」 (slave) 節點。從節點僅提供讀取服務，當主節點故障時，可手動或自動提升其中一個從節點為新的主節點。
1.1 基本設定流程
-- 在 Master 上啟用 binary log
[mysqld]
log-bin=mysql-bin
server-id=1
-- 在 Slave 上設定唯一的 server-id，並指向 Master
[mysqld]
server-id=2
relay-log=relay-bin
relay-log-index=relay-bin.index
-- 在 Master 建立複製專用使用者
CREATE USER 'repl'@'%' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
-- 在 Slave 設定複製來源
CHANGE MASTER TO
MASTER_HOST='master_ip',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS= 107;
START SLAVE;
註解：
log-bin讓 MySQL 把所有變更寫入 binary log。server-id必須在同一叢集內唯一。CHANGE MASTER TO中的MASTER_LOG_FILE與MASTER_LOG_POS需根據SHOW MASTER STATUS的輸出填入。
2. 多主複製 (Master‑Master Replication)
若寫入流量大、或需要資料中心跨區容錯，雙主 (master‑master) 方案可同時接受寫入。兩個節點互為對方的從端，形成環形同步。
2.1 注意衝突解決
- 自動遞增主鍵：使用
auto_increment_increment與auto_increment_offset，確保兩端產生的 PK 不會重複。 - 衝突檢測：若同一筆資料在兩端同時被更新，最後寫入的節點會覆寫另一端，必須在應用層做好衝突處理或使用行級鎖。
-- 設定兩個 Master 的自增規則
-- Master A
[mysqld]
server-id=1
auto_increment_increment=2
auto_increment_offset=1
-- Master B
[mysqld]
server-id=2
auto_increment_increment=2
auto_increment_offset=2
-- 在 Master A 設定對 Master B 的複製
CHANGE MASTER TO
MASTER_HOST='masterB_ip',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS= 107;
START SLAVE;
-- 同理，在 Master B 設定對 Master A 的複製
CHANGE MASTER TO
MASTER_HOST='masterA_ip',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS= 107;
START SLAVE;
3. MHA (MySQL Master High Availability)
MHA 是一套由 GitHub 開源 的自動故障轉移 (failover) 解決方案，核心概念是：
- 監控：MHA Manager 持續檢測 Master 的健康狀態。
- 自動選舉：當 Master 掛掉，MHA 會根據 GTID、二進位日誌位置 等資訊挑選最適合的從節點作為新 Master。
- 切換：自動執行
STOP SLAVE、RESET MASTER、START SLAVE等指令，完成主從角色的切換，且 不需要重啟 MySQL 服務。
3.1 MHA 基本安裝與設定
# 安裝 MHA Manager（以 Ubuntu 為例）
sudo apt-get install mha-manager mha-node
# /etc/mha.cnf
[server default]
user = mha
password = mha_password
[server1]
hostname = master_ip
port = 3306
candidate_master = 1 # 標示此節點可以被選為新 Master
[server2]
hostname = slave1_ip
port = 3306
[server3]
hostname = slave2_ip
port = 3306
# 啟動 MHA 監控
masterha_manager --conf=/etc/mha.cnf --ignore_last_check 1 &
小技巧：將 MHA 的監控腳本加入
systemd，確保系統重啟後自動恢復。
4. Galera Cluster (基於同步多主)
Galera 為 同步 多主叢集，所有節點寫入的資料會即時同步至其他節點，保證 資料一致性。適合需要 零資料遺失、高寫入併發 的場景，例如電商訂單系統。
4.1 主要特性
| 特性 | 說明 |
|---|---|
| 同步複製 | 交易在提交前必須得到多數節點的確認 (quorum)。 |
| 自動分片 | 只要節點加入/離開，Galera 會自動重新平衡資料。 |
| 無需額外代理 | 應用直接連到任一節點即可讀寫。 |
4.2 基本部署範例（三節點）
# 安裝 Galera 套件（以 CentOS 為例）
yum install -y mariadb-server galera-4 rsync
# /etc/my.cnf.d/galera.cnf
[mysqld]
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
query_cache_type=0
bind-address=0.0.0.0
# Galera 相關設定
wsrep_on=ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_name="my_galera_cluster"
wsrep_cluster_address="gcomm://node1_ip,node2_ip,node3_ip"
wsrep_node_address="node1_ip"
wsrep_node_name="node1"
wsrep_sst_method=rsync
# 在第一台節點啟動集群（其他節點使用普通方式啟動）
galera_new_cluster
systemctl start mariadb
# 在其餘節點啟動 MariaDB（會自動加入集群）
systemctl start mariadb
注意：若任意節點發生網路分割 (split‑brain)，Galera 會根據 最小同步數 (default: 2) 決定哪一側保留，另一側會自動轉為只讀。
常見陷阱與最佳實踐
| 陷阱 | 說明 | 最佳做法 |
|---|---|---|
| 單點故障仍然存在 | 只在資料層做 HA，卻忽略了 DNS、負載平衡器、儲存設備等。 | 同時在 網路層 部署 HAProxy、Keepalived，確保 IP 轉移不會卡住。 |
| 自增主鍵衝突 | 多主環境若未設定 auto_increment_increment/offset，會導致 PK 重複。 |
為每個節點設定唯一的 offset，或改用 UUID、Snowflake。 |
| 延遲的從端讀取舊資料 | 主從複製是非同步的，從端可能落後。 | 讀寫分離時，將寫入操作或需要即時一致性的查詢 路由到主節點。 |
| GTID 不一致 | 在使用 GTID 複製時，手動修改 binlog 會導致 GTID 不匹配。 | 避免手動編輯 binlog，使用 SET GTID_NEXT 進行特殊操作。 |
| 網路分割 (Split‑brain) | 多主叢集若網路斷開，會產生兩個獨立的主體。 | 使用 Quorum 機制、設定 evs.suspect_timeout，或在 Keepalived 中加入 vrrp_instance 的 nopreempt。 |
額外建議
- 定期 備份：即使 HA 可避免服務中斷，資料損毀仍可能發生。使用 Percona XtraBackup 或 MySQL Enterprise Backup。
- 監控指標：監測
Seconds_Behind_Master、Replica_lag、wsrep_cluster_size、wsrep_local_state_comment，並設定告警。 - 測試故障轉移：每次升級或變更後，務必在測試環境模擬主節點失效，驗證自動切換流程。
實際應用場景
| 場景 | 推薦架構 | 為什麼適合 |
|---|---|---|
| 電商網站的訂單系統 | Galera Cluster（同步多主）+ HAProxy | 訂單必須即時寫入且不容許遺失，讀寫皆可在任一節點完成，提供極低延遲。 |
| 報表與分析平台 | 主從複製 + MHA | 報表查詢可放在從節點，主節點只負責寫入，MHA 確保主節點故障時快速自動切換。 |
| 跨地域備援 | 多主複製 + Keepalived 虛擬 IP | 兩個資料中心各有一個 Master，互為對等，可在其中一個中心失效時仍持續提供服務。 |
| 開發測試環境 | 單機 MySQL + Docker + 監控腳本 | 透過 Docker Compose 快速部署主從，方便開發人員測試故障轉移流程。 |
| 金融交易系統 | MHA + Percona XtraDB Cluster (PXC) | 需要高可用 + 強一致性，MHA 處理自動故障切換，PXC 提供同步複製與線上擴容。 |
總結
MySQL 的高可用架構不再是「只有大企業」才能使用的專屬技術。從最簡單的 主從複製、到自動化的 MHA，再到提供 同步多主 的 Galera Cluster，每一種方案都針對不同的業務需求與資源限制提供了可行的解決方式。
- 了解自己的需求：是偏向讀寫分離、跨地域容錯，還是零資料遺失的交易系統？
- 選擇合適的工具：根據需求選擇單主、雙主、MHA、Galera 或 Percona XtraDB Cluster。
- 做好監控與測試：即使是最成熟的 HA 解決方案，也需要持續的監控、備份與故障演練。
只要遵循本文的 概念、範例與最佳實踐，你就能在自己的專案中建立可靠、可彈性擴充的 MySQL 高可用環境，讓服務在任何突發狀況下仍能穩定運作。祝你部署順利、系統永遠在線！