5. Binary Log Filters
It is possible to filter out statements from the binary log using two
options: binlog-do-db and
binlog-ignore-db (which we will call
binlog-*-db collectively). The
binlog-do-db is used when you want to
filter only statements belonging to a certain database, and the binlog-ignore-db is used when you want to
ignore a certain database but replicate all other databases.
These options can be given multiple times, so to filter out both
the database one_db and the database
two_db, you must give both options in
the my.cnf file, for
example:
[mysqld]
binlog-ignore-db=one_db
binlog-ignore-db=two_db
The way MySQL filters events can be quite a surprise to unfamiliar
users, so we’ll explain how filtering works and make some
recommendations on how to avoid some of the major headaches.
Figure 1 shows
how MySQL determines whether the statement is filtered. The filtering is
done on a statement level—either the entire statement is filtered or the
entire statement is written to the binary log—and the binlog-*-db options use the current database to decide whether
the statement should be filtered, not the database of the table affected
by the statement.
To help you understand the behavior, Example 4 shows some statements
that change tables in different databases. Each line uses test as the current database:
Line 1 changes a table in the current database named test since it does not qualify the table
name with a database name.
Line 2 changes a table in a different database than the
current database.
Line 3 changes two tables in two different databases, neither
of which is the current database.
Example 4. Statements using different databases
USE bad; INSERT INTO t1 VALUES (1),(2);
USE bad; INSERT INTO good.t2 VALUES (1),(2);
USE bad; UPDATE good.t1, ugly.t2 SET a = b;
|
Consider what happens if the bad database is
filtered using binlog-ignore-db=bad.
None of the three statements in Example 3-4 will be written to the
binary log, even though the second and third statements change tables on
the good and ugly database.
This might seem strange at first—why not filter the statement based on
the database of the table changed? But consider what would happen with
the third statement if the
ugly database was filtered instead of the
bad database. Now one database in the UPDATE is filtered out and other isn’t. This
puts the server in a catch-22 situation, so the problem is solved by
just filtering on the current database, and this rule is used for all
statements (with a few exceptions).
Note:
To avoid mistakes when executing statements that can potentially
be filtered, make it a habit not to write statements so they qualify
table, function, or procedure names with the database name. Instead,
whenever you want to access a table in a different database, issue a
USE statement to make that database
the current database. In other words, instead of writing:
INSERT INTO other.book VALUES ('MySQL', 'Paul DuBois');
write:
USE other; INSERT INTO book VALUES ('MySQL', 'Paul DuBois');
So, what happens when both binlog-do-db and binlog-ignore-db are used at the same time?
For example, consider a configuration file containing the following two
rules:
[mysqld]
binlog-do-db=good
binlog-ignore-db=bad
In this case, will the following statement be filtered or
not?
USE ugly; INSERT INTO t1 VALUES (1);
Following the diagram in Figure 3-3, you can see that if
there is at least a binlog-do-db
rule, all binlog-ignore-db rules are
ignored completely, and since only the good
database is included, the statement above will be filtered.
Warning:
Because of the way that the binlog-*-db rules are evaluated, it is
pointless to have both binlog-do-db
and binlog-ignore-db rules at the
same time. The recommendation is to not use the
binlog-*-db options, because the
binary log can be used for recovery as well as replication. If you
filter out statements from the binary log, you will be unable to
restore the database from the binary log in the event of a
crash.
