前言：為什么需要主從復制過濾？

在實際生產(chǎn)環(huán)境中，MySQL 主從復制架構幾乎是標配，但默認的全量同步往往會帶來不必要的資源消耗 —— 比如日志表、測試表的數(shù)據(jù)同步，不僅占用從庫磁盤空間，還會增加網(wǎng)絡傳輸壓力。因此，精細化控制同步范圍（只同步核心數(shù)據(jù)、忽略非必要表 / 庫）就顯得尤為重要。

最近剛好在優(yōu)化公司的主從架構，整理了一套完整的過濾配置實驗方案，從環(huán)境準備到六種核心場景測試，全程實操驗證，今天就把這些干貨分享給大家～

一、實驗環(huán)境準備（基礎鋪墊不能少）

首先得有一個正常運行的 MySQL 主從架構（主從已實現(xiàn)基礎同步），我這里用的是 MySQL 8.0 版本，操作系統(tǒng)是 CentOS 7。

1.1 主庫：創(chuàng)建測試數(shù)據(jù)

為了驗證不同過濾規(guī)則，我特意創(chuàng)建了 2 個庫、4 張表，包含業(yè)務表、日志表，方便后續(xù)區(qū)分測試：

-- 創(chuàng)建測試庫

create database db1;

create database db2;

-- db1庫：業(yè)務表+日志表（模擬真實場景）

use db1;

create table table_01(id int not null auto_increment primary key, name varchar(10));

create table table_02(id int not null auto_increment primary key, name varchar(10));

create table log_01(id int not null auto_increment primary key, name varchar(10)); -- 擬忽略的日志表

-- db2庫：普通測試表

use db2;

create table test_01(id int not null auto_increment primary key, name varchar(10));

然后插入隨機測試數(shù)據(jù)（用 MD5 生成隨機字符串，不用手動造數(shù)據(jù)，效率超高）：

insert into db1.table_01(name) values (SUBSTRING(MD5(RAND()), 1, 10));

insert into db1.table_02(name) values (SUBSTRING(MD5(RAND()), 1, 10));

insert into db1.log_01(name) values (SUBSTRING(MD5(RAND()), 1, 10));

insert into db2.test_01(name) values (SUBSTRING(MD5(RAND()), 1, 10));

1.2 從庫：驗證初始同步

這一步很關鍵！必須先確認主從基礎同步正常，不然后續(xù)過濾測試就沒意義了。在從庫執(zhí)行查詢：

select * from db1.table_01;

select * from db1.table_02;

select * from db1.log_01;

select * from db2.test_01;

如果都能查到數(shù)據(jù)，說明主從架構沒問題，可以開始過濾配置了～

二、六種核心過濾方案（場景化實操）

所有過濾規(guī)則都在從庫配置，記住一個通用流程：停止SQL線程 → 配置規(guī)則 → 重啟SQL線程 → 測試效果 → 清理規(guī)則，避免規(guī)則殘留影響后續(xù)測試。

2.1 方案 1：只復制某一個庫（REPLICATE_DO_DB）

適用場景：只需要同步核心業(yè)務庫（比如 db1），非核心庫（如 db2）無需同步。

-- 臨時配置（不用重啟，測試用超方便）

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_DO_DB=(db1);

start slave sql_thread;

show slave status\G; -- 查看Filter參數(shù)是否生效

如果需要長期生效，就要改配置文件（記得重啟服務）：

vim /data/mysql/conf/my.cnf

replicate-do-db=db1  # 新增配置

systemctl restart mysqld

測試結果：主庫往 db1 插數(shù)據(jù)同步成功，db2 插數(shù)據(jù)從庫無反應，符合預期～

2.2 方案 2：忽略某個庫（REPLICATE_IGNORE_DB）

適用場景：除了某個庫（比如日志庫 db1），其他庫都要同步。

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB=(db1);

start slave sql\_thread;

測試感悟：這個規(guī)則適合把測試庫、日志庫排除在外，減少從庫壓力，親測好用！

2.3 方案 3：只復制指定表（REPLICATE_DO_TABLE）

適用場景：同一庫下只需要同步核心表（比如 db1.table_01），其他表忽略。

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_DO_TABLE=(db1.table_01); -- 必須寫"庫名.表名"

start slave sql_thread;

注意：如果只寫表名會失效！之前踩過這個坑，大家一定要注意～

2.4 方案 4：忽略指定表（REPLICATE_IGNORE_TABLE）

適用場景：同步某庫大部分表，但忽略日志表、臨時表（比如 db1.log_01）。

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE=(db1.log_01);

start slave sql_thread;

實操心得：日志表數(shù)據(jù)量大且無需備份，用這個規(guī)則能節(jié)省大量磁盤空間～

2.5 方案 5：通配符匹配同步表（REPLICATE_WILD_DO_TABLE）

適用場景：同步某庫下符合前綴 / 后綴規(guī)則的表（比如 db1 下所有 table 開頭的表）。

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE=('db1.table%'); -- 通配符%匹配任意字符

start slave sql_thread;

配置文件持久化（不用加引號）：

replicate-wild-do-table=db1.table%

測試效果：table_01、table_02 都能同步，log_01 被忽略，批量匹配超高效！

2.6 方案 6：通配符忽略表（REPLICATE_WILD_IGNORE_TABLE）

適用場景：忽略某庫下符合規(guī)則的表（比如 db1 下所有 table 開頭的表）。

STOP SLAVE SQL_THREAD;

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE=('db1.table%');

start slave sql_thread;

使用建議：如果需要批量排除同類表，這個規(guī)則比逐個寫 REPLICATE_IGNORE_TABLE 更方便。

三、實驗總結（快速選型指南）

整理了一張對比表，大家可以根據(jù)業(yè)務場景直接選型：

四、避坑指南（實操經(jīng)驗分享）

1. 配置優(yōu)先級：臨時配置（CHANGE REPLICATION FILTER）比配置文件優(yōu)先級高，測試時用臨時配置，確定后再寫配置文件。
2. 規(guī)則沖突：如果同時配置 “只復制” 和 “忽略”，忽略規(guī)則優(yōu)先級更高！比如既配置了 REPLICATE_DO_DB=db1，又配置了 REPLICATE_IGNORE_TABLE=db1.table_01，那么 table_01 會被忽略。
3. 大小寫問題：Linux 環(huán)境下 MySQL 默認區(qū)分表名大小寫，配置時要和實際表名一致（比如 table_01 不能寫成 Table_01），否則規(guī)則失效！
4. 重啟影響：臨時配置重啟從庫后會丟失，生產(chǎn)環(huán)境一定要用配置文件持久化。
5. 數(shù)據(jù)清理：實驗結束后記得在主從庫同時刪除測試庫（drop database db1; drop database db2;），避免殘留數(shù)據(jù)干擾。

最后

以上就是 MySQL 主從復制過濾配置的全部實操內(nèi)容啦～ 其實過濾規(guī)則不難，關鍵是根據(jù)業(yè)務場景選對方案，并且注意避坑。如果大家有其他場景的過濾需求，或者在實操中遇到問題，歡迎在評論區(qū)交流探討！

以上就是MySQL主從復制過濾配置的完整方案的詳細內(nèi)容，更多關于MySQL主從復制過濾配置的資料請關注腳本之家其它相關文章！

最新評論