Duplicate binlog-do-db entry — Solution

Posted in: MySQL, Technical Track

At the November MySQL User Group, Patrick Galbraith ran into a problem where binlog-do-db was duplicated. It manifests itself like this:

(copied from http://lists.mysql.com/replication/607)

master my.cnf:

slave my.cnf:

Relevant show slave status output

Replicate_Do_DB: db1;,db1;

When db1 is modified on master, Read_Master_Log_Pos and Relay_Log_Pos do
changes, also I can open and see the changes in rh3-relay-bin.000002, but
they do not appear in database.  No error logged in /var/lib/mysql/rh3.err

Replicate_Do_DB is showing database name twice. I am not sure why.

Well, it’s a bug. Patrick confirmed that upgrading fixed his bug.

From the manual:

Incompatible Change: It was possible for option files to be read twice at program startup, if some of the standard option file locations turned out to be the same directory. Now duplicates are removed from the list of files to be read.

Unfortunately, this is an enterprise release. Even more sadly, http://www.dorsalsource.org does not have the source or binaries for the most recent Enterprise version, MySQL 5.0.54. On a tangent, nor does it have sources/binaries for the most recent community version, 5.0.51. Dorsal Source, we’ve come to depend on you!

Happily, I have been able to find that Jason Litka has posted the source rpm to http://www.jasonlitka.com/2007/12/27/upgrading-to-mysql-5054-on-rhel-and-centos/

Even more happily, he has a yum repository with binaries. The binary I was looking for is in here, so perhaps it will be there for you as well.

I hope this helps folks! It seemed like the duplicate binlog-do-db was a problem. (and yes, I realize in the example above the original poster had a problem with a semicolon, using binlog-do-db=db1; instead of just binlog-do-db=db1 — but the problem is the same nonetheless).


Interested in working with Sheeri? Schedule a tech call.

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *