When evaluating replication or binary logging 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.)
An exception is made in the rules just given for the
CREATE DATABASE,
ALTER DATABASE, and
DROP DATABASE statements (see
Section 14.8.4, “Binary Log Options and Variables”). In those
cases, the database being created, altered, or
dropped replaces the default database when
determining whether to log or to ignore updates.
The checking of the database-level options proceeds as shown in this 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 the next step.
--replicate-do-db and
--replicate-ignore-db
options.
Proceed to checking the table-level replication options,
if there are any.
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 a description of how the table-level replication options are checked, see Section 14.9.2, “Evaluation of Table-Level Replication Options”.
--binlog-do-db and
--binlog-ignore-db options.
Execute the statement and exit.
--binlog-do-db can sometimes mean
“ignore other databases”. For example, a slave
running with only
--binlog-do-db=sales does not
write to the binary log any statement for which the default
database is different from sales.


User Comments
Add your own comment.