目錄
前言
一、架構原理?
?Keepalived 作用?
?MySQL 主從復制?
二、環境準備??
服務器要求?:
? ? ? 安裝基礎軟件?
三、配置 MySQL 主從復制
四、配置 Keepalived
主節點配置?(/etc/keepalived/keepalived.conf)
從節點配置
五、啟動與驗證
六、注意事項?
前言
????????使用 Keepalived 實現 MySQL 高可用(HA)的核心是通過 ?虛擬 IP(VIP)漂移? 在主節點故障時自動切換流量到備用節點,結合 MySQL 主從復制保證數據一致性。以下是詳細步驟和配置說明:
一、架構原理?
-
?Keepalived 作用?
- 基于 VRRP 協議管理 VIP,主節點正常時持有 VIP。
- 通過健康檢查腳本監控 MySQL 服務狀態,若主節點故障,VIP 漂移到備用節點。
- 客戶端通過 VIP 訪問 MySQL,無需感知后端節點切換
-
?MySQL 主從復制?
- 主節點(Master)處理寫請求,從節點(Slave)同步數據。
- 故障切換后,原從節點提升為新主節點(需配合復制配置或工具)
二、環境準備??
-
服務器要求?:
- 兩臺 Linux 服務器(如 CentOS 7+),分別部署 MySQL 主從復制。
- 示例 IP:
- 主節點:192.168.71.177
- 從節點:192.168.71.169
- 虛擬 IP(VIP):192.168.71.100
? ? ? 安裝基礎軟件?
# 在兩臺服務器上安裝 MySQL 和 Keepalived
yum install -y mysql-server keepalived
systemctl enable mysqld keepalived
三、配置 MySQL 主從復制
創建了一個測試用的數據庫
主節點配置?(my.cnf):
[mysqld]
server-id = 1
log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db = your_database # 需同步的數據庫
?從節點配置(my.cnf)
[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin
啟動復制
-- 在主節點創建復制用戶
CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';-- 在從節點配置主庫信息
CHANGE MASTER TO
? MASTER_HOST='192.168.71.177',
? MASTER_USER='repl',
? MASTER_PASSWORD='password';
START SLAVE;
驗證同步:SHOW SLAVE STATUS\G
?檢查?Slave_IO_Running: Yes
四、配置 Keepalived
主節點配置?(/etc/keepalived/keepalived.conf
)
global_defs {router_id mysql_master # 唯一標識,建議用主機名
}vrrp_script chk_mysql {script "/usr/bin/mysqladmin ping" # MySQL 健康檢查命令interval 2 # 每 2 秒檢查一次weight 2 # 檢查失敗時降低優先級
}vrrp_instance VI_1 {state MASTERinterface eth0 # 綁定 VIP 的網卡virtual_router_id 51 # 集群 ID,主從必須一致priority 100 # 主節點優先級更高(范圍 1-254)advert_int 1 # 心跳間隔authentication {auth_type PASSauth_pass 1111 # 主從密碼需相同}virtual_ipaddress {192.168.71.100/24 dev eth0 # VIP 配置}track_script {chk_mysql # 引用健康檢查腳本}notify_master "/path/to/promote_script.sh" # 切換為主時執行的腳本(可選)
}
從節點配置
五、啟動與驗證
啟動服務?:
主
從
?故障轉移測試?:
模擬主節點故障?
觀察 VIP 漂移?:
在從節點執行?ip addr
,應看到 VIP 綁定到從節點網卡。
主:
從:
客戶端連接測試?:
恢復主節點?:
- 重啟主節點 MySQL 后,若需切回 VIP,可手動重啟主節點 Keepalived(或通過優先級調整)
此時從節點無法登錄
六、注意事項?
- ?數據一致性風險?:
- 主從復制延遲可能導致數據丟失。建議啟用半同步復制(Semi-Sync Replication)或 GTID
- ?腦裂問題?:
- 確保?
virtual_router_id
?唯一,避免多個集群沖突
- 確保?
- ?自動切換限制?:
- Keepalived 僅負責 VIP 漂移,?不會自動切換 MySQL 主從角色。需配合腳本或工具(如 MHA、Orchestrator)實現完整故障轉移
- ?監控與告警?:
- 配置 Keepalived 郵件通知(
global_defs
?區塊),實時感知切換事件
- 配置 Keepalived 郵件通知(