If a master server does not write a statement to its binary log, the statement is not replicated. If the server does log the statement, the statement is sent to all slaves and each slave determines whether to execute it or ignore it.
On the master, you can control which databases to log changes for
by using the
--binlog-ignore-db options to
control binary logging. For a description of the rules that
servers use in evaluating these options, see
Section 14.9.1, “Evaluation of Database-Level Replication and Binary Logging Options”. You should not use
these options to control which databases and tables are
replicated. Instead, use filtering on the slave to control the
events that are executed on the slave.
On the slave side, decisions about whether to execute or ignore
statements received from the master are made according to the
--replicate-* options that the slave was started
with. (See Section 14.8, “Replication and Binary Logging Options and Variables”.) The slave
evaluates these options using the procedure described later in
this section, which first checks the database-level options and
then the table-level options.
In the simplest case, when there are no
--replicate-* options, the slave executes all
statements that it receives from the master. Otherwise, the result
depends on the particular options given. In general, to make it
easier to determine what effect an option set will have, it is
recommended that you avoid mixing “do” and
“ignore” options, or wildcard and nonwildcard
--replicate-ignore-db) are checked
first; see Section 14.9.1, “Evaluation of Database-Level Replication and Binary Logging Options”, for a
description of this process. If no matching database-level options
are found, option checking proceeds to any table-level options
that may be in use, as discussed in
Section 14.9.2, “Evaluation of Table-Level Replication Options”.
options were specified, they are applied before the
--replicate-* filtering rules are tested.