MySQL 自動化恢復方案：基於 Binlog 的增量備份與主從架構設計實戰

架構背景

單機備份在大數據量下耗時長、佔空間、恢復慢。構建**主從復制 + 定期全量備份 + Binlog 增量**架構，實現 RPO 接近 0、RTO 分鐘級的自動化恢復能力。

核心組件

1. 主庫：開啟 Binlog (ROW 格式)、配置 server_id、創建復制賬號
2. 從庫：同步主庫數據、作為備份源、可掛載只讀業務
3. 備份節點：從從庫拉取全量備份 (避免主庫壓力)、存儲 Binlog 歸檔
4. 恢復編排：腳本自動化「全量恢復 + Binlog 重放」流程

主庫配置標準化

[mysqld]
server_id = 1
log_bin = /data/mysql/binlog/mysql-bin
binlog_format = ROW
binlog_expire_logs_seconds = 604800  # 7天
max_binlog_size = 100M
sync_binlog = 1
binlog_checksum = CRC32
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON  # 從庫也記 Binlog，支持級聯

# 復制用戶
CREATE USER 'repl'@'%' IDENTIFIED BY 'StrongPass123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

從庫部署流程 (標準化)

# 1. 從庫配置
[mysqld]
server_id = 2
log_bin = /data/mysql/binlog/mysql-bin
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
log_slave_updates = ON
read_only = ON  # 防止誤寫入
relay_log = /data/mysql/relaylog/relay-bin

# 2. 從主庫獲取同步座標 (GTID 模式無需座標)
# 主庫執行：
SHOW MASTER STATUS;  -- 記錄 File, Position (非 GTID 時)
# 或
SELECT @@GLOBAL.GTID_EXECUTED;  -- GTID 集合

# 3. 建立復制
CHANGE MASTER TO
  MASTER_HOST='10.0.1.100',
  MASTER_USER='repl',
  MASTER_PASSWORD='StrongPass123!',
  MASTER_AUTO_POSITION=1;  # GTID 模式
START SLAVE;

# 4. 驗證
SHOW SLAVE STATUS\G
-- Slave_IO_Running: Yes
-- Slave_SQL_Running: Yes
-- Seconds_Behind_Master: 0

備份策略：分層分級

Binlog 實時歸檔腳本 (關鍵：連續模式)

#!/bin/bash
# binlog_archiver.sh - 以 daemon 方式運行
BINLOG_DIR="/data/mysql/binlog"
ARCHIVE_DIR="/backup/binlog_archive"
MASTER_HOST="10.0.1.100"
REPL_USER="binlog_archiver"
REPL_PASS="xxx"

mkdir -p "$ARCHIVE_DIR"

# 持續追蹤最新 Binlog，類似 tail -f
mysqlbinlog \
  --host="$MASTER_HOST" \
  --user="$REPL_USER" \
  --password="$REPL_PASS" \
  --raw \
  --continuous \
  --stop-never \
  --result-file="$ARCHIVE_DIR/" \
  mysql-bin.000001  # 從首個開始，自動跟隨 rotate

此進程長期運行，將主庫 Binlog 實時下載到備份存儲，**實現秒級 RPO**。

自動化恢復編排流程

# restore_orchestrator.sh  [target_server_id]
TARGET_DT=$1
TARGET_SID=${2:-1}

# 1. 選擇最近的全量備份 (T0 <= TARGET_DT)
LATEST_FULL=$(find /backup/full -name "*.xbstream" -newerct "$TARGET_DT - 24 hours" | sort | tail -1)

# 2. 解壓全量備份到目標實例數據目錄
mkdir -p /var/lib/mysql_restore
xbstream -x < "$LATEST_FULL" -C /var/lib/mysql_restore
xtrabackup --prepare --target-dir=/var/lib/mysql_restore

# 3. 修正 server_id、UUID (避免衝突)
sed -i "s/server_id = .*/server_id = $TARGET_SID/" /var/lib/mysql_restore/backup-my.cnf
# 重新生成 auto.cnf (server_uuid)
rm -f /var/lib/mysql_restore/auto.cnf

# 4. 啟動臨時實例 (端口 3307)
mysqld --defaults-file=/var/lib/mysql_restore/backup-my.cnf \
       --datadir=/var/lib/mysql_restore \
       --port=3307 \
       --socket=/tmp/mysql_restore.sock &

# 5. 重放 Binlog 到 TARGET_DT
mysqlbinlog \
  --start-datetime="$(grep 'xtrabackup_binlog_pos' /var/lib/mysql_restore/xtrabackup_binlog_info | cut -d' ' -f1)" \
  --stop-datetime="$TARGET_DT" \
  /backup/binlog_archive/mysql-bin.* \
  | mysql -uroot -p -S /tmp/mysql_restore.sock

# 6. 驗證關鍵業務表
mysql -uroot -p -S /tmp/mysql_restore.sock -e "
  SELECT COUNT(*) FROM business.orders WHERE created_at < '$TARGET_DT';
  SELECT MAX(updated_at) FROM business.users;
"

# 7. 切換流量 (修改 DNS/Proxy/應用配置指向 3307)
# 8. 原實例降級/銷毀

監控與告警體系

# 關鍵指標
- Seconds_Behind_Master > 300  → 告警 (主從延遲)
- Binlog 磁盤用量 > 80%  → 告警 (清理/擴容)
- xtrabackup 失敗  → 立即告警
- Binlog 歸檔進程存活  → 進程監控
- 備份文件完整性校驗 (sha256)  → 定期校驗

避坑指南

現代替代：MySQL Shell / Mydumper / 云托管備份

• MySQL Shell：util.dumpInstance() 並行導出、util.loadDump() 並行導入、支持壓縮、加密、OCI 對象存儲直傳
• Mydumper/Myloader：多線程邏輯備份/恢復，比 mysqldump 快 5-10 倍
• 云托管 (RDS/CloudSQL/PolarDB)：自動備份、PITR 一鍵恢復、跨區域複製、無需自建腳本

總結

自動化恢復體系 = **主從復制 (實時同步) + 分級備份 (全量/增量/Binlog歸檔) + 編排腳本 (標準化流程) + 監控告警 (可觀測性) + 定期演練 (驗證可用性)**。

核心指標：**RPO < 1 分鐘 (Binlog 歸檔)、RTO < 30 分鐘 (並行恢復 + 預熱緩存)**。將恢復能力從「手藝活」轉化為「標準化產品」，是數據庫團隊走向成熟的標誌。