Binlog 核心作用
- 主從同步：Slave IO 線程拉取 Binlog 事件
- 數據恢復：記錄所有 DDL/DML 操作及執行時間，支持 PITR
環境準備與 Binlog 啟用
cat /var/lib/mysql/mysql-bin.index
# mysql-bin.000001
# mysql-bin.000002 (重啟/FLUSH LOGS 產生新文件)
2. 解析最新 Binlog 定位誤操作 Position
# 僅導出 Position 2698 之前（含正常增量，排除兩次誤操作）
mysqlbinlog --stop-position=2698 /var/lib/mysql/mysql-bin.000001 > /tmp/Backup_1.sql
4. 清理環境並恢復
5. 驗證恢復結果
生產級 PITR 三種恢復策略對比
| 策略 | 適用場景 | 步驟 | RPO/RTO |
|---|
| 全量備份 + Binlog 位置/時間 | 標準場景，Binlog 完整 | 全量導入 → Binlog 截取 → 導入 | RPO 秒級 / RTO 分鐘級 |
| 純 Binlog 合並恢復 | 全量備份缺失，但 Binlog 從初始完整保留 | 所有 Binlog 按位置/時間合並 → 導入 | RPO 秒級 / RTO 較長 |
| 直接全量備份恢復 | 誤操作後數據可接受丟失，或 Binlog 損壞 | 僅導入最近全量備份 | RPO 備份間隔 / RTO 最快 |
官方建議備份原則（睡個好覺）
- 安裝即開啟 log-bin，存放於獨立磁盤/RAID，確保存儲安全
- 定期全量備份：每日/每周
mysqldump --single-transaction --master-data=2
- 定期 FLUSH LOGS：
mysqladmin flush-logs 切割 Binlog，便於增量備份與管理
- 異地備份：Binlog 與全量備份同步至異地存儲/雲對象存儲
- 定期演練：月度恢復演練，驗證備份可用性與流程熟練度
避坑指南
- ❌ 恢復期間允許業務寫入 → 主鍵衝突/數據不一致 → 加鎖/停服/只讀模式
- ❌ 直接導入含誤操作的 Binlog → 重複執行誤操作 → 必須手動/腳本剔除誤操作語句
- ❌ 忽略 Binlog 文件編號斷層 → 遺漏增量 → 按 mysql-bin.index 列表依序處理
- ✅ 恢復前備份當前狀態（哪怕是壞的），留存取證
