Documentation Home
MySQL 5.5 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 27.2Mb
PDF (A4) - 27.2Mb
PDF (RPM) - 26.2Mb
HTML Download (TGZ) - 6.6Mb
HTML Download (Zip) - 6.6Mb
HTML Download (RPM) - 5.6Mb
Man Pages (TGZ) - 170.5Kb
Man Pages (Zip) - 278.9Kb
Info (Gzip) - 2.6Mb
Info (Zip) - 2.6Mb
Excerpts from this Manual

MySQL 5.5 Reference Manual  /  ...  /  Evaluation of Database-Level Replication and Binary Logging Options

17.2.3.1 Evaluation of Database-Level Replication and Binary Logging Options

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.

The database that is checked for a match depends on the binary log format of the statement that is being handled. If the statement has been logged using the row format, the database where data is to be changed is the database that is checked. If the statement has been logged using the statement format, the default database (specified with a USE statement) is the database that is checked.

Note

Only DML statements can be logged using the row format. DDL statements are always logged as statements, even when binlog_format=ROW. All DDL statements are therefore always filtered according to the rules for statement-based replication. This means that you must select the default database explicitly with a USE statement in order for a DDL statement to be applied.

Checking of database-level options proceeds as shown in the following diagram:

Evaluation of Database-Level Filtering Rules in Replication

For replication, the steps involved are listed here:

  1. Are there any --replicate-do-db options?

    • Yes.  Do any of them match the database?

      • Yes.  Execute the statement and exit.

      • No.  Ignore the statement and exit.

    • No.  Continue to step 2.

  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.

  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”.

    Important

    A 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:

  1. Are there any --binlog-do-db or --binlog-ignore-db options?

    • Yes.  Continue to step 2.

    • No.  Log the statement and exit.

  2. Is there a default database (has any database been selected by USE)?

    • Yes.  Continue to step 3.

    • No.  Ignore the statement and exit.

  3. 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.

  4. Do any of the --binlog-ignore-db options match the database?

    • Yes.  Ignore the statement and exit.

    • No.  Log the statement and exit.

Important

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
  Posted by Jörg Brühe on August 11, 2017
There seems to be a different handling of the default database between "--replicate-do-db" and "--replicate-wild-do-table":
If no default database is set (no "use" statement issued), a statement "create table X.tabelle ..." will not be applied on the slave even though "--replicate-do-db = X" was given.
If "--replicate-wild-do-table = X.%" was given, the statement will be applied and the table will be created.

See https://bugs.mysql.com/bug.php?id=77673 for a discussion.
Sign Up Login You must be logged in to post a comment.