Comments on: Why MySQL’s binlog-do-db option is dangerous http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/ Percona's MySQL & InnoDB performance and scalability blog Sat, 11 Feb 2012 16:45:54 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Simon Mudd http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/comment-page-1/#comment-563807 Simon Mudd Tue, 19 May 2009 23:20:13 +0000 http://www.mysqlperformanceblog.com/?p=689#comment-563807 Row based replication in 5.1 makes this sort of thing clearer and that's almost certainly one of the reasons it was added. For certain SQL statements it can also be much quicker. The whole replicate-wild* or replicate*ignore options would be so much better handled if they were done differently, for example as done by Sybase were you can easily configure replication on a per table basis. Even having a few mysql.XXXX tables which define the replication rules would be better than using the my.cnf only options. I've only looked in detail at Sybase replication, so am not sure what is offered by Oracle or other commercial RDBMS vendors. MySQL's replication facilities for simple stuff is great, but the moment you want to do things in a slightly more complex fashion opens the way for potential headaches if you are not really aware of how replication works in MySQL. Which is why I stand by the claim in my blog posting a while back that it would be so much better if replication were pulled out of mysqld and moved to a separate process dedicated to the task. Then as mentioned the binlog could be used for what it's supposed to be: point in time recovery and the replication process could be improved without having to worry so much about what goes on in the database. Row based replication in 5.1 makes this sort of thing clearer and that’s almost certainly one of the reasons it was added. For certain SQL statements it can also be much quicker.

The whole replicate-wild* or replicate*ignore options would be so much better handled if they were done differently, for example as done by Sybase were you can easily configure replication on a per table basis.

Even having a few mysql.XXXX tables which define the replication rules would be better than using the my.cnf only options. I’ve only looked in detail at Sybase replication, so am not sure what is offered by Oracle or other commercial RDBMS vendors. MySQL’s replication facilities for simple stuff is great, but the moment you want to do things in a slightly more complex fashion opens the way for potential headaches if you are not really aware of how replication works in MySQL.

Which is why I stand by the claim in my blog posting a while back that it would be so much better if replication were pulled out of mysqld and moved to a separate process dedicated to the task.

Then as mentioned the binlog could be used for what it’s supposed to be: point in time recovery and the replication process could be improved without having to worry so much about what goes on in the database.

]]> By: Morgan Christiansson http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/comment-page-1/#comment-561591 Morgan Christiansson Fri, 15 May 2009 05:35:21 +0000 http://www.mysqlperformanceblog.com/?p=689#comment-561591 Shantanu, there is also --replicate-do-table and --replicate-wild-do-table which have different behaviour than --binlog-do-db See http://dev.mysql.com/doc/refman/5.0/en/replication-options-slave.html#option_mysqld_replicate-do-table http://dev.mysql.com/doc/refman/5.0/en/replication-options-slave.html#option_mysqld_replicate-wild-do-table The documentation even says "This works for cross-database updates, in contrast to --replicate-ignore-db." But you still need to be aware of it's quirks, queries that JOIN the wrong tables in updates could leave your replication out of sync. Shantanu, there is also –replicate-do-table and –replicate-wild-do-table which have different behaviour than –binlog-do-db

See
http://dev.mysql.com/doc/refman/5.0/en/replication-options-slave.html#option_mysqld_replicate-do-table
http://dev.mysql.com/doc/refman/5.0/en/replication-options-slave.html#option_mysqld_replicate-wild-do-table

The documentation even says “This works for cross-database updates, in contrast to –replicate-ignore-db.”

But you still need to be aware of it’s quirks, queries that JOIN the wrong tables in updates could leave your replication out of sync.

]]> By: Shantanu Oak http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/comment-page-1/#comment-561581 Shantanu Oak Fri, 15 May 2009 04:56:17 +0000 http://www.mysqlperformanceblog.com/?p=689#comment-561581 >> Because binlog-ignore-db doesn't do what you think. I wish it did what it says. It would have brought down the network traffic when I have to update the slaves located in other cities. >> Because binlog-ignore-db doesn’t do what you think.
I wish it did what it says. It would have brought down the network traffic when I have to update the slaves located in other cities.

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/comment-page-1/#comment-561574 Baron Schwartz Fri, 15 May 2009 03:31:37 +0000 http://www.mysqlperformanceblog.com/?p=689#comment-561574 Morgan, I have slowly come to realize that most people never read the manual. They read wikihow.com or some other garbage and think they know things. Sad but true. Morgan, I have slowly come to realize that most people never read the manual. They read wikihow.com or some other garbage and think they know things. Sad but true.

]]> By: Morgan Christiansson http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/comment-page-1/#comment-561546 Morgan Christiansson Fri, 15 May 2009 02:04:37 +0000 http://www.mysqlperformanceblog.com/?p=689#comment-561546 Which is why this behaviour is very clearly documented in the MySQL manual for this setting. http://dev.mysql.com/doc/refman/5.0/en/replication-options-binary-log.html Which is why this behaviour is very clearly documented in the MySQL manual for this setting.

http://dev.mysql.com/doc/refman/5.0/en/replication-options-binary-log.html

]]> By: Robert Hodges http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/comment-page-1/#comment-561477 Robert Hodges Fri, 15 May 2009 00:40:03 +0000 http://www.mysqlperformanceblog.com/?p=689#comment-561477 Master side filtering has a host of pitfalls, but even so it is sometimes necessary. Applications can turn off the binlog for selected statements using SET SQL_LOG_BIN=0. That's better because at least you presumably know exactly what you are doing at the application level. We use this feature for Tungsten Replicator catalogs--replicating them would break our application. We have very flexible filters both on the master as well as the slave but our experience has been exactly what Baron found, namely that filtering on the slave is best. Master side filtering has a host of pitfalls, but even so it is sometimes necessary. Applications can turn off the binlog for selected statements using SET SQL_LOG_BIN=0. That’s better because at least you presumably know exactly what you are doing at the application level. We use this feature for Tungsten Replicator catalogs–replicating them would break our application. We have very flexible filters both on the master as well as the slave but our experience has been exactly what Baron found, namely that filtering on the slave is best.

]]> By: peter http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/comment-page-1/#comment-561176 peter Thu, 14 May 2009 15:58:30 +0000 http://www.mysqlperformanceblog.com/?p=689#comment-561176 Sheeri, Indeed - so any binlog filtering is evil if you care about your data. With row level replication it is probably safe to skip tables which you do not care about such as temporary tables from the logging but this is about it. Sheeri,

Indeed – so any binlog filtering is evil if you care about your data.
With row level replication it is probably safe to skip tables which you do not care about such as temporary tables from the logging but this is about it.

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/comment-page-1/#comment-561173 Baron Schwartz Thu, 14 May 2009 14:26:54 +0000 http://www.mysqlperformanceblog.com/?p=689#comment-561173 John, yes that's true. John, yes that’s true.

]]> By: Sheeri K. Cabral http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/comment-page-1/#comment-561172 Sheeri K. Cabral Thu, 14 May 2009 14:24:38 +0000 http://www.mysqlperformanceblog.com/?p=689#comment-561172 The other important issue to consider is that binary logs are not only used for replication. They are incremental backups, and if you chose to use the "do" statements, you are effectively erasing history, and should you have a disaster and need the incremental backups, there is no way to retrieve the ignored information. The other important issue to consider is that binary logs are not only used for replication. They are incremental backups, and if you chose to use the “do” statements, you are effectively erasing history, and should you have a disaster and need the incremental backups, there is no way to retrieve the ignored information.

]]> By: John Swindells http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/comment-page-1/#comment-561167 John Swindells Thu, 14 May 2009 14:07:14 +0000 http://www.mysqlperformanceblog.com/?p=689#comment-561167 This is good to know. Is it true, therefore, that binlog-do-db behaves itself if you have always selected your database beforehand? When you say 'default database', does that include a database selected by USE DATABASE? This is good to know. Is it true, therefore, that binlog-do-db behaves itself if you have always selected your database beforehand? When you say ‘default database’, does that include a database selected by USE DATABASE?

]]>