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. 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 And don't forget to issue a 'start slave' on both systems! --- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
