content_image/865264.jpg
7. Is there another table to be tested? 

• Yes.  Go back to step 3. 

• No.  Continue to step 8. 

8. Are there any --replicate-do-table  or --replicate-wild-do-table  options? 

## 17.2.5.3 Interactions Between Replication Filtering Options 

• Yes.  Ignore the update and exit. 

• No.  Execute the update and exit. 

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

## Note 

Statement-based replication stops if a single SQL statement operates on both a table that is included by a --replicate-do-table  or --replicate-wild- do-table  option, and another table that is ignored by a --replicate-ignore- table  or --replicate-wild-ignore-table  option. The replica must either execute or ignore the complete statement (which forms a replication event), and it cannot logically do this. This also applies to row-based replication for DDL statements, because DDL statements are always logged as statements, without regard to the logging format in effect. The only type of statement that can update both an included and an ignored table and still be replicated successfully is a DML statement that has been logged with binlog_format=ROW . 

If you use a combination of database-level and table-level replication filtering options, the replica first accepts or ignores events using the database options, then it evaluates all events permitted by those options according to the table options. This can sometimes lead to results that seem counterintuitive. It is also important to note that the results vary depending on whether the operation is logged using statement- based or row-based binary logging format. If you want to be sure that your replication filters always operate in the same way independently of the binary logging format, which is particularly important if you are using mixed binary logging format, follow the guidance in this topic. 

The effect of the replication filtering options differs between binary logging formats because of the way the database name is identified. With statement-based format, DML statements are handled based on the current database, as specified by the USE  statement. With row-based format, DML statements are handled based on the database where the modified table exists. DDL statements are always filtered based on the current database, as specified by the USE  statement, regardless of the binary logging format. 

An operation that involves multiple tables can also be affected differently by replication filtering options depending on the binary logging format. Operations to watch out for include transactions involving multi- table UPDATE  statements, triggers, cascading foreign keys, stored functions that update multiple tables, and DML statements that invoke stored functions that update one or more tables. If these operations update both filtered-in and filtered-out tables, the results can vary with the binary logging format. 

If you need to guarantee that your replication filters operate consistently regardless of the binary logging format, particularly if you are using mixed binary logging format ( binlog_format=MIXED ), use only table- level replication filtering options, and do not use database-level replication filtering options. Also, do not use multi-table DML statements that update both filtered-in and filtered-out tables. 

If you need to use a combination of database-level and table-level replication filters, and want these to operate as consistently as possible, choose one of the following strategies: 

1. If you use row-based binary logging format ( binlog_format=ROW ), for DDL statements, rely on the USE  statement to set the database and do not specify the database name. You can consider 

