我的任務是在從屬主機上設置複製。主數據庫是一個“數據儲存”，每天都會在其中刪除、重新創建和重新載入表。

我的從屬主機的初始設置通過複製工作得很好，總是比主機晚幾天。在與“數據儲存”的使用者交談後，我意識到並非所有數據庫和所有表都需要複製。所以這就是我所做的

CI-DB002-PRD [root@localhost] ON (none)>  STOP SLAVE\G

CI-DB002-PRD [root@localhost] ON (none)> CHANGE REPLICATION FILTER REPLICATE_DO_DB = (bidw,cf2_fact,ct_fact,ez_fact,gt_fact,sfdc,soa_fact,tesla_fact,tmc_fact);

CI-DB002-PRD [root@localhost] ON (none)> CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('bidw.domo%', 'bidw.consolidated%', 'bidw.cf2%', 'bidw.tesla%');

CI-DB002-PRD [root@localhost] ON (none)>  START SLAVE\G

很快，複製趕上了，現在，從伺服器落後主伺服器 3-7 秒。

但是複制並沒有觸及我想要複製的數據庫。即使對於我上面列出的模式，master 上的數據每 10 分鐘更改一次。我做了幾個驗證查詢，結果現在不同。當我檢查我的奴隸的狀態時，沒有什麼特別突出的

CI-DB002-PRD [root@localhost] ON (none)> show slave status\G
*************************** 1. row ***************************
              Slave_IO_State: Queueing master event to the relay log
                 Master_Host: 10.239.0.34
                 Master_User: ci02replicadb
                 Master_Port: 3306
               Connect_Retry: 60
             Master_Log_File: binary-log.009871
         Read_Master_Log_Pos: 14678596
              Relay_Log_File: ci-db002-prd-relay-bin.007914
               Relay_Log_Pos: 814824
       Relay_Master_Log_File: binary-log.009871
            Slave_IO_Running: Yes
           Slave_SQL_Running: Yes
             Replicate_Do_DB: bidw,cf2_fact,ct_fact,ez_fact,gt_fact,sfdc,soa_fact,tesla_fact,tmc_fact,staging,phoenix,data_science
         Replicate_Ignore_DB:
          Replicate_Do_Table:
      Replicate_Ignore_Table:
     Replicate_Wild_Do_Table: bidw.domo%,bidw.consolidated%,bidw.cf2%,bidw.tesla%,bidw.ez%,bidw.ct%,bidw.gt%,bidw.tmc%,bidw.did%,bidw.Shortened%,bidw.other_revenue%,bidw.revenue%,bidw.advanced_cohort%
 Replicate_Wild_Ignore_Table:
                  Last_Errno: 0
                  Last_Error:
                Skip_Counter: 0
         Exec_Master_Log_Pos: 814626
             Relay_Log_Space: 14679056
             Until_Condition: None
              Until_Log_File:
               Until_Log_Pos: 0
          Master_SSL_Allowed: No
          Master_SSL_CA_File:
          Master_SSL_CA_Path:
             Master_SSL_Cert:
           Master_SSL_Cipher:
              Master_SSL_Key:
       Seconds_Behind_Master: 22
Master_SSL_Verify_Server_Cert: No
               Last_IO_Errno: 0
               Last_IO_Error:
              Last_SQL_Errno: 0
              Last_SQL_Error:
 Replicate_Ignore_Server_Ids:
            Master_Server_Id: 1
                 Master_UUID: a485ab14-aa57-11ea-bef5-42010aef0022
            Master_Info_File: /data/mysql/master.info
                   SQL_Delay: 0
         SQL_Remaining_Delay: NULL
     Slave_SQL_Running_State: Reading event from the relay log
          Master_Retry_Count: 86400
                 Master_Bind:
     Last_IO_Error_Timestamp:
    Last_SQL_Error_Timestamp:
              Master_SSL_Crl:
          Master_SSL_Crlpath:
          Retrieved_Gtid_Set:
           Executed_Gtid_Set:
               Auto_Position: 0
        Replicate_Rewrite_DB:
                Channel_Name:
          Master_TLS_Version:
1 row in set (0.01 sec)

對於“Replicate_Wild_Do_Table”，我只複製那裡列出的表，因為整個“bidw”數據庫的垃圾表都很糟糕。

我在這裡想念什麼？我不能同時使用兩個過濾器嗎？我的版本是 5.7.31。

這是我公司的一篇舊部落格：設置 MySQL 複製過濾器的最佳實踐。

它部分說：

MySQL 為設置複製提供了 3 級過濾器：Binary log、DB 和 Table。binlog 過濾器應用於 master 以控制如何記錄更改。由於 MySQL 複製是基於 binlog 的，所以它是第一級過濾器，具有最高的優先級。雖然 DB 級和表級過濾器適用於從屬設備，但由於每個表都屬於一個模式，因此 DB 級過濾器的優先級高於表級過濾器。在表級過濾器中，MySQL 將按以下順序評估選項：–replicate-do-table、–replicate-ignore-table、 –replicate-wild-do-table、–replicate-wild-ignore-table。

鑑於此聲明並查看您的SHOW SLAVE STATUS\G，我將執行以下操作之一：

1. bidw從列表中刪除Replicate_Do_DB（至少）
2. 刪除Replicate_Wild_Do_Table並遷移所有垃圾表
3. 完全刪除Replicate_Do_DB列表（最後的手段）

更新 2020-08-12 10:54 EDT

為了進一步澄清，Replicate_Do_DB允許數據庫中的所有內容及其祖母midw進行複制，Replicate_Wild_Do_Table結果實際上被忽略了。

引用自：https://dba.stackexchange.com/questions/273641