OK, it turns out that I was rather stupid when configuring the my.cnf. As it turned out, the effect I was seeing was due to the presence of two log-bin lines, which looked like the following:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
[mysqld] port = 3306 datadir = /mysql/dbase log = /mysql/logs/dbc-mysql1.log log-error = /mysql/logs/dbc-mysql1.err socket = /var/lib/mysql/mysql.sock bind = 172.16.234.31 # custom paths for binary logs log-bin = /mysql/binlogs/dbc-mysql1 log-bin-index = /mysql/binlogs/dbc-mysql1.idx relay-log = /mysql/binlogs/dbc-mysql1.relay |
And some lines down there was this:
|
1 2 |
# custom paths for binary logs log-bin |
Now the next thing I encountered was while importing our old databases (they are like 1.1GiB each, 25 databases total). The second MySQL Master (and his Slave) will choke as soon as you dump the data too fast into the first Master, as the binlog seems to be too big for MySQL to transfer it via TCP (smth like “Packet too large – try increasing max_packet_size” in the error-log; only problem was that max_packet_size was already at 1GiB which is the absolut maximum for MySQL 5.0 according to the handbook).
A way around this (thanks to a co-worker who pushed me towards this road) is disabling all the MySQL Master/Slave stuff in your my.cnf, start the mysql daemon as a simple, dumb database, import all your databases, stop the mysql daemon; tar up the whole BASEDIR and scp/rssh it to your second master.
Clean out the BASEDIR on the second master, untar your tarball, edit your my.cnf again to include the whole Master/Slave portions on both boxes and you should be up and running 😀
I haven’t run any tests on the MasterMaster replication yet, but I’ll do that as soon as I’m at work again (which is the 27th June, as I’m off for vacation since yesterday, yay!)