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 18.104.22.168, “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 16.1.4, “Replication and Binary Logging Options and Variables”.) In MySQL 5.7.3
and later, the filters governed by these options can also be set
dynamically using the
CHANGE REPLICATION FILTER
statement. The rules governing such filters are the same whether
they are created on startup using
options or while the slave server is running by
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.
--replicate-ignore-db) are checked
first; see Section 22.214.171.124, “Evaluation of Database-Level Replication and Binary Logging Options”, for a
description of this process. If no database-level options are
used, option checking proceeds to any table-level options that may
be in use (see Section 126.96.36.199, “Evaluation of Table-Level Replication Options”,
for a discussion of these). If one or more database-level options
are used but none are matched, the statement is not replicated.
For statements affecting databases only (that is,
DROP DATABASE, and
ALTER DATABASE), database-level
options always take precedence over any
In other words, for such statements,
are checked if and only if there are no database-level options
that apply. This is a change in behavior from previous versions of
MySQL, where the statement
dbx was not replicated if the slave had been started
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 options.
options were specified, they are applied before the
--replicate-* filtering rules are tested.
In MySQL 5.7, all replication filtering options
follow the same rules for case sensitivity that apply to names
of databases and tables elsewhere in the MySQL server, including
the effects of the
This is a change from previous versions of MySQL. (Bug #51639)
Copyright © 1997, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices