MySQL binlog-do-db 參數對 Binlog 寫入影響深度解析：主從一致性陷阱

一、實驗環境與參數

• OS: SuSE 11 SP1 x86_64
• MySQL: 5.5.37
• 參數: binlog-do-db = bosco1
• 測試庫: bosco1 (目標庫), bosco2 (非目標庫)
• 隔離級別: REPEATABLE-READ

二、實驗 1：USE bosco2 (非目標庫) + STATEMENT/ROW 格式

mysql> USE bosco2;
mysql> SELECT @@binlog_format;  -- STATEMENT 或 ROW
mysql> FLUSH LOGS;

mysql> CREATE TABLE bosco1.bosco1_tb01(id INT);
mysql> CREATE TABLE bosco2.bosco2_tb01(id INT);
mysql> INSERT INTO bosco1.bosco1_tb01(id) VALUES(1);
mysql> INSERT INTO bosco2.bosco2_tb01(id) VALUES(1);
mysql> FLUSH LOGS;

Binlog 內容 (mysqlbinlog 解析)：

# 只有 Rotate 事件，無任何 DDL/DML 記錄！
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
# at 4
#141026 1:41:09 server id 1303308 end_log_pos 107 Start: binlog v 4
# at 107
#141026 1:43:02 server id 1303308 end_log_pos 150 Rotate to mysql-bin.000014 pos: 4

結論：

當 USE 非 binlog-do-db 庫 時，所有操作（含跨庫操作目標庫的表）均不記錄 Binlog，無論 STATEMENT 或 ROW 格式。DDL 也不記錄。

三、實驗 2：USE bosco1 (目標庫) + ROW 格式

mysql> USE bosco1;
mysql> SET @@binlog_format = ROW;
mysql> FLUSH LOGS;

mysql> CREATE TABLE bosco1.bosco1_tb01(id INT);
mysql> CREATE TABLE bosco2.bosco2_tb01(id INT);
mysql> INSERT INTO bosco1.bosco1_tb01(id) VALUES(1);
mysql> INSERT INTO bosco2.bosco2_tb01(id) VALUES(1);
mysql> FLUSH LOGS;

Binlog 內容：

# DDL 均記錄
CREATE TABLE bosco1.bosco1_tb01(id INT)
CREATE TABLE bosco2.bosco2_tb01(id INT)

# DML：僅記錄目標庫表的 INSERT
BEGIN
Table_map: bosco1.bosco1_tb01 mapped to number 49
WRITE_ROWS: INSERT INTO bosco1.bosco1_tb01 SET @1=1
COMMIT

# bosco2.bosco2_tb01 的 INSERT **不記錄**

結論：

ROW 格式下，USE 目標庫 時：DDL 全記錄（跨庫也記錄），DML 僅記錄目標庫表，非目標庫表 DML 被過濾。

四、實驗 3：USE bosco1 (目標庫) + STATEMENT/MIXED 格式

mysql> USE bosco1;
mysql> SET @@binlog_format = STATEMENT;  -- MIXED 同理
mysql> FLUSH LOGS;

mysql> CREATE TABLE bosco1.bosco1_tb01(id INT);
mysql> CREATE TABLE bosco2.bosco2_tb01(id INT);
mysql> INSERT INTO bosco1.bosco1_tb01(id) VALUES(1);
mysql> INSERT INTO bosco2.bosco2_tb01(id) VALUES(1);
mysql> FLUSH LOGS;

Binlog 內容：

# DDL 全記錄
CREATE TABLE bosco1.bosco1_tb01(id INT)
CREATE TABLE bosco2.bosco2_tb01(id INT)

# DML **全部記錄**（含非目標庫表！）
BEGIN
INSERT INTO bosco1.bosco1_tb01(id) VALUES(1)
COMMIT

BEGIN
INSERT INTO bosco2.bosco2_tb01(id) VALUES(1)   <-- 非目標庫表也記錄了！
COMMIT

結論：

STATEMENT/MIXED 格式下，USE 目標庫 時：所有庫的 DML 均記錄，binlog-do-db 過濾**完全失效**。DDL 也全記錄。

五、行為總結矩陣

六、主從不一致風險場景

1. 應用未顯式 USE 目標庫： 連接池預設庫非目標庫，所有寫入不進 Binlog → 從庫無數據
2. 跨庫操作： INSERT INTO target_db.t SELECT * FROM other_db.t 在非目標庫會話下不記錄
3. STATEMENT 格式假象： 以為過濾生效，實則全記錄，浪費 Binlog 空間且從庫可能報錯
4. DDL 洩露： 所有 DDL 記錄導致從庫執行非預期結構變更

七、官方文檔核心說明

"binlog-do-db 在 STATEMENT 格式下基於『當前默認數據庫』判斷，而非『實際操作的數據庫』。 ROW 格式下基於『實際修改的表所屬數據庫』判斷。"

八、安全替代方案

九、binlog-ignore-db 同理分析

binlog-ignore-db 行為與 binlog-do-db 完全對稱，同樣受 binlog_format 和 USE database 影響，同樣不建議在主庫使用。

十、最佳實踐建議

1. 主庫不做庫級過濾： 保證 Binlog 完整記錄所有變更，支援任意從庫拓撲
2. 從庫配置 replicate-do-db/table： 按業務需求在從庫端過濾
3. 統一使用 ROW 格式： binlog_format = ROW，行級記錄，語義明確，支援異構複製
4. 啟用 GTID： gtid_mode=ON, enforce_gtid_consistency=ON，簡化故障轉移與過濾
5. 定期一致性校驗： 使用 pt-table-checksum / mysqlbinlog 對比主從

binlog-do-db 是一個「看似簡單、實則暗坑」的參數。其行為強依賴會話上下文與 Binlog 格式，極易在應用升級、連接池變更、格式切換時產生靜默數據丟失。堅持「主庫全量 Binlog，從庫按需過濾」原則，是構建穩健 MySQL 複製架構的基石。