On 01/13/2011 09:51 PM, Paul J Stevens wrote:
On 01/13/2011 09:07 PM, Gordan Bobic wrote:
You'll find the master will grind to a halt anyway while you're doing
this, as soon as the write-ahead log fills up. With small-ish databases
it's not a big deal, but if the size is in the 100GB+ range the rsync
method will be a lot more workable.
Fair enough. My method is aimed at being reliably script-able and
without *any* downtime, so slave initialization can be done without time
pressure. But I've never had to witness the gridlock you mention.
I've used your method plenty back when mysql-replication still sucked
bad and started to suffer from sync conflicts on myisam tables every
month or so. The rsync method you described is solid. One detail I miss
is what to do with the master.info file.
Well, you can either check the log position in it and initialize the
slave to that, or remove it along with the binlogs (if you have no other
slaves running) and let the slave start replicating from log 0 position
0, which it will do by default.
One way that should work is hard-coding the master-* parameters in
my.cnf, and simply remove the master.info files when priming the slave.
--- db1.my.net:/etc/mysqld/my.cnf ---
[mysqld]
server-id = 1
master-host = db2.my.net
master-user = replicationuser
master-password = replicationpassword
master-port = 3306
--- db2.my.net:/etc/mysqld/my.cnf ---
[mysqld]
server-id = 2
master-host = db1.my.net
master-user = replicationuser
master-password = replicationpassword
master-port = 3306
Indeed. But those will start to get ignored after the first startup.
Thereafer, the info in master.info will be used. In fact, the official
line is that setting this up in my.cnf is deprecated.
Gordan
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
