content_image/852326.jpg content_image/852321.jpg content_image/852327.jpg
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20; 

If you are using statement-based replication, then both tables are updated on the replica. However, when using row-based replication, only table1  is affected on the replica; since table2  is in a different database, table2  on the replica is not changed by the UPDATE . Now suppose that, instead of the USE db1  statement, a USE db4  statement had been used: 

USE db4; UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20; 

In this case, the UPDATE  statement would have no effect on the replica when using statement-based replication. However, if you are using row-based replication, the UPDATE  would change table1  on the replica, but not table2 —in other words, only tables in the database named by --replicate-do-db are changed, and the choice of default database has no effect on this behavior. 

If you need cross-database updates to work, use --replicate-wild-do-table= db_name .% instead. See Section 17.2.5, “How Servers Evaluate Replication Filtering Rules” . 

<img src='content_image/852326.jpg'>

• --replicate-ignore-db= db_name 

## Note 

This option affects replication in the same manner that --binlog-do-db  affects binary logging, and the effects of the replication format on how --replicate- do-db  affects replication behavior are the same as those of the logging format on the behavior of --binlog-do-db . 

This option has no effect on BEGIN , COMMIT , or ROLLBACK  statements. 

<img src='content_image/852321.jpg'>

Creates a replication filter using the name of a database. Such filters can also be created using CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB . 

This option supports channel specific replication filters, enabling multi-source replicas to use specific filters for different sources. To configure a channel specific replication filter on a channel named channel_1  use --replicate-ignore-db: channel_1 : db_name . In this case, the first colon is interpreted as a separator and subsequent colons are literal colons. See Section 17.2.5.4, “Replication Channel Based Filters”  for more information. 

<img src='content_image/852327.jpg'>

## Note 

Global replication filters cannot be used on a MySQL server instance that is configured for Group Replication, because filtering transactions on some servers would make the group unable to reach agreement on a consistent state. Channel specific replication filters can be used on replication channels that are not directly involved with Group Replication, such as where a group member also acts as a replica to a source that is outside the group. They cannot be used on 

