您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 資料庫相關知識

MySQL 5.0 主從複寫配置實戰：RedHat 環境下的資料同步部署

編輯：MySQL 資料庫相關知識

前言

MySQL Replication（主從複寫）是實現資料庫高可用、讀寫分離、異地備援的核心架構。本文以 MySQL 5.0.15 on RedHat ES 3 為實測環境，記錄從權限授予、資料初始化、雙端 my.cnf 參數調校到驗證同步狀態的完整部署流程，供維護舊版本系統或學習複寫原理的工程師參考。

架構規劃

角色	IP 位址	Hostname	Server ID
Master (A)	192.168.1.2	master-db	1
Slave (B)	192.168.1.3	slave-db	2

同步目標資料庫：gbbbs
忽略同步系統庫：mysql、test、information_schema

階段一：Master 端配置

1. 建立複寫專用帳號

mysql -u root -p
GRANT FILE ON *.* TO 'backup'@'192.168.1.3' IDENTIFIED BY '1234';
FLUSH PRIVILEGES;
EXIT;

說明：FILE 權限供 LOAD DATA INFILE 等操作使用，實際複寫僅需 REPLICATION SLAVE，但舊版本常搭配 FILE 授予。建議最小權限原則：GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.3' IDENTIFIED BY 'strong_pass';

2. 關閉 Master 並匯出基準資料

mysqladmin -u root -p shutdown
# 使用 mysqldump 匯出需同步的資料庫
mysqldump -u root -p --databases gbbbs --master-data=2 --single-transaction > /tmp/master_gbbbs.sql
# 將檔案傳輸至 Slave 主機
scp /tmp/master_gbbbs.sql 192.168.1.3:/tmp/

3. 修改 /etc/my.cnf [mysqld] 區段

[mysqld]
log-bin=mysql-bin
server-id=1
binlog_do_db = gbbbs
binlog_ignore_db = mysql,test,information_schema
sync_binlog = 1          # 強制每次 commit 刷寫 binlog，保障資料不遺失
innodb_flush_log_at_trx_commit = 1

參數解析：

log-bin：啟用二進位日誌，複寫核心依賴
binlog_do_db：僅記錄指定資料庫變更，減少 Binlog 體積
binlog_ignore_db：排除系統庫，避免不必要同步
sync_binlog=1 + innodb_flush_log_at_trx_commit=1：「雙 1」配置，犧牲部分效能換取最高資料安全性

4. 重啟 MySQL 服務

service mysqld restart
# 或 /etc/init.d/mysqld restart

階段二：Slave 端配置

1. 匯入基準資料

mysql -u root -p < /tmp/master_gbbbs.sql

2. 修改 /etc/my.cnf [mysqld] 區段

[mysqld]
server-id = 2
master-host = 192.168.1.2
master-user = backup
master-password = 1234
master-port = 3306
master-connect-retry = 60
replicate-do-db = gbbbs
# replicate-do-db = database2  # 多資料庫同步時新增行
log-warnings = 1
relay-log = relay-bin
relay-log-index = relay-bin.index
read-only = 1              # 防止誤在 Slave 寫入造成資料不一致

3. 重啟 MySQL 並啟動複寫

service mysqld restart
mysql -u root -p -e "START SLAVE;"

4. 驗證複寫狀態

mysql -u root -p -e "SHOW SLAVE STATUS\G"

關鍵指標應顯示：

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
Last_IO_Error: 
Last_SQL_Error:

另可查看資料目錄下的 master.info、relay-log.info 確認同步位點。

常見問題排查

現象	可能原因	解決方向
IO_Running: No	網路不通、帳號密碼錯誤、Master 防火牆阻擋 3306	telnet 測試連線、檢查 Master `bind-address`、授權主機名/IP
SQL_Running: No	資料衝突（主鍵重複）、Schema 不同、觸發器/存儲程序錯誤	查看 `Last_SQL_Error`、手動修正衝突後 `SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;`
Seconds_Behind_Master 偏大	Slave 處理能力不足、長事務阻塞、網路延遲	優化 Slave 硬體/參數、拆分大事務、啟用平行複寫（5.6+）
Binlog 格式不相容	Master/Slave 版本差異大、`binlog_format` 設定不同	統一設定 `binlog_format=ROW`（建議）或 MIXED

安全與維護建議

專用複寫帳號：僅授予 REPLICATION SLAVE、REPLICATION CLIENT 權限，密碼高強度
SSL 加密複寫連線：配置 master-ssl=1 相關參數，防止 Binlog 傳輸被竊聽
監控告警：監控 Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running，異常即時通知
定期校驗：使用 pt-table-checksum（Percona Toolkit）驗證主從資料一致性
備份策略：在 Slave 執行 mysqldump --single-transaction --master-data=2 降低 Master 負載

版本升級提示

MySQL 5.0 已終止支援，新部署建議使用 MySQL 5.7/8.0 或 MariaDB 10.x。新版本複寫優勢：

GTID（全域交易識別碼）簡化故障切換與拓撲變更
平行複寫（Multi-threaded Slave）大幅提升 Slave 回放效能
半同步複寫（Semi-sync）在效能與資料安全間取得平衡
CHANGE MASTER TO 動態修改參數無需編輯 my.cnf 重啟

結語

MySQL 5.0 主從複雜雖屬經典架構，但其核心原理——Binlog 傳輸、Relay Log 回放、位點追蹤——貫穿至今所有版本。掌握舊版本手動配置流程，有助於深入理解複寫機制，為未來升級至 GTID 架構打下堅實基礎。生產環境務必落實「監控、校驗、備份、演練」四大支柱，確保資料同步的可靠與可控。