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-db
options?
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-db
options?
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 16.2.3.2, “Evaluation of Table-Level Replication Options”.
A statement that is not yet disallowed 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-db
or --binlog-ignore-db
options?
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-db
options?
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-db
options
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
.
User Comments
Add your own comment.