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: binlog-do-db=db1 slave my.cnf: replicate-do-db=db1; 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 file. 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! EDIT: Proven Scaling has updated their mirror at http://mirror.provenscaling.com/mysql/! Thank 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).
Leave a Reply