When evaluating replication options, the slave begins by
checking to see whether there are any
--replicate-do-db or
--replicate-ignore-db options
that apply. When using
--binlog-do-db or
--binlog-ignore-db, the process
is similar, but the options are checked on the master.
With statement-based replication, the default database is checked for a match. With row-based replication, the database where data is to be changed is the database that is checked. Regardless of the binary logging format, checking of database-level options proceeds as shown in the following diagram.
The steps involved are listed here:
Are there any
--replicate-do-dboptions?Yes. Do any of them match the database?
Yes. Execute the statement and exit.
No. Continue to step 2.
No. Continue to step 2.
Are there any
--replicate-ignore-dboptions?Yes. Do any of them match the database?
Yes. Ignore the statement and exit.
No. Continue to step 3.
No. Continue to step 3.
Proceed to checking the table-level replication options, if there are any. For a description of how these options are checked, see Section 17.2.3.2, “Evaluation of Table-Level Replication Options”.
ImportantA statement that is still permitted at this stage is not yet actually executed. The statement is not executed until all table-level options (if any) have also been checked, and the outcome of that process permits execution of the statement.
For binary logging, the steps involved are listed here:
Are there any
--binlog-do-dbor--binlog-ignore-dboptions?Yes. Continue to step 2.
No. Log the statement and exit.
Is there a default database (has any database been selected by
USE)?Yes. Continue to step 3.
No. Ignore the statement and exit.
There is a default database. Are there any
--binlog-do-dboptions?Yes. Do any of them match the database?
Yes. Log the statement and exit.
No. Ignore the statement and exit.
No. Continue to step 4.
Do any of the
--binlog-ignore-dboptions match the database?Yes. Ignore the statement and exit.
No. Log the statement and exit.
For statement-based logging, an exception is made in the rules
just given for the CREATE
DATABASE, ALTER
DATABASE, and DROP
DATABASE statements. In those cases, the database
being created, altered, or dropped
replaces the default database when determining whether to log
or ignore updates.
--binlog-do-db can sometimes mean
“ignore other databases”. For example, when using
statement-based logging, a server running with only
--binlog-do-db=sales does not
write to the binary log statements for which the default
database differs from sales. When using
row-based logging with the same option, the server logs only
those updates that change data in sales.