How Servers Evaluate Replication Filtering Rules changing to row-based binary logging format for improved consistency with replication filtering. See Section 5.4.4.2, “Setting The Binary Log Format”  for the conditions that apply to changing the binary logging format. Example 17.7 A  --replicate-ignore-db  option and a  --replicate-do-table  option On the replication source server, the following statements are issued: The replica has the following replication filtering options set: replicate-ignore-db = db1 replicate-do-table = db2.t3 The DDL statement  CREATE TABLE  creates the table in  db1 , as specified by the preceding  USE statement. The replica filters out this statement according to its  --replicate-ignore-db = db1 option, because  db1  is the current database. This result is the same whatever the binary logging format is on the replication source server. However, the result of the DML  INSERT  statement is different depending on the binary logging format: If the  --replicate-ignore-db = db1  option on the replica is necessary, and the use of statement- based (or mixed) binary logging format on the source is also necessary, the results can be made consistent by omitting the database name from the  INSERT  statement and relying on a  USE  statement instead, as follows: In this case, the replica always evaluates the  INSERT  statement based on the database  db2 . Whether the operation is logged in statement-based or row-based binary format, the results remain the same. This section explains how to work with replication filters when multiple replication channels exist, for example in a multi-source replication topology. Before MySQL 8.0, replication filters were global, so filters were applied to all replication channels. From MySQL 8.0, replication filters can be global or channel specific, enabling you to configure multi-source replicas with replication filters on specific replication channels. Channel specific replication filters are particularly useful in a multi-source replication topology 3611 17.2.5.4 Replication Channel Based Filters 2. If you use statement-based or mixed binary logging format ( binlog_format=STATEMENT  or  MIXED ), for both DML and DDL statements, rely on the  USE  statement and do not use the database name. Also, do not use multi-table DML statements that update both filtered-in and filtered-out tables. •If row-based binary logging format is in use on the source ( binlog_format=ROW ), the replica evaluates the  INSERT  operation using the database where the table exists, which is named as  db2 . The database- level option  --replicate-ignore-db = db1 , which is evaluated first, therefore does not apply. The table-level option  --replicate-do-table = db2.t3  does apply, so the replica applies the change to table  t3 . •If statement-based binary logging format is in use on the source ( binlog_format=STATEMENT ), the replica evaluates the  INSERT  operation using the default database, which was set by the  USE  statement to  db1  and has not been changed. According to its database-level  --replicate-ignore-db = db1 option, it therefore ignores the operation and does not apply the change to table  t3 . The table-level option  --replicate-do-table = db2.t3  is not checked, because the statement already matched a database-level option and was ignored. USE db1; CREATE TABLE t2 LIKE t1; USE db2; INSERT INTO t3 VALUES (1); USE db1; CREATE TABLE t2 LIKE t1; INSERT INTO db2.t3 VALUES (1);