content_image/856135.jpg content_image/856134.jpg
<img src='content_image/856135.jpg'>

This option affects binary logging in a manner similar to the way that --replicate-do-db  affects replication. 

The effects of this option depend on whether the statement-based or row-based logging format is in use, in the same way that the effects of --replicate-do-db  depend on whether statement-based or row-based replication is in use. You should keep in mind that the format used to log a given statement may not necessarily be the same as that indicated by the value of binlog_format . For example, DDL statements such as CREATE TABLE  and ALTER TABLE  are always logged as statements, without regard to the logging format in effect, so the following statement-based rules for --binlog-do-db always apply in determining whether or not the statement is logged. 

Statement-based logging.  Only those statements are written to the binary log where the default database (that is, the one selected by USE ) is db_name . To specify more than one database, use this option multiple times, once for each database; however, doing so does not  cause cross-database statements such as UPDATE some_db.some_table  SET foo=’bar’  to be logged while a different database (or no database) is selected. 

<img src='content_image/856134.jpg'>

## Warning 

To specify multiple databases you must  use multiple instances of this option. Because database names can contain commas, the list is treated as the name of a single database if you supply a comma-separated list. 

An example of what does not work as you might expect when using statement-based logging: If the server is started with --binlog-do-db=sales  and you issue the following statements, the UPDATE statement is not  logged: 

USE prices; UPDATE sales.january SET amount=amount+1000; 

The main reason for this “just check the default database”  behavior is that it is difficult from the statement alone to know whether it should be replicated (for example, if you are using multiple-table DELETE statements or multiple-table UPDATE  statements that act across multiple databases). It is also faster to check only the default database rather than all databases if there is no need. 

Another case which may not be self-evident occurs when a given database is replicated even though it was not specified when setting the option. If the server is started with --binlog-do-db=sales , the following UPDATE  statement is logged even though prices  was not included when setting --binlog- do-db : 

USE sales; UPDATE prices.discounts SET percentage = percentage + 10; 

Because sales  is the default database when the UPDATE  statement is issued, the UPDATE  is logged. 

Row-based logging.  Logging is restricted to database db_name . Only changes to tables belonging to db_name  are logged; the default database has no effect on this. Suppose that the server is started with --binlog-do-db=sales  and row-based logging is in effect, and then the following statements are executed: 

USE prices; 

