If you're making backups of the DB, it might be possible to use the backup data as a replication snapshot for kickstarting the slave. You would need to be recording the master log file and position at the time the backups are made as well, however (usually easy to hack in if you're not already recording this). You are making backups, right? :)
Here's another possibility, although not one I would really recommend: 1) Import all schema's into the slave 2) Set up replication (don't bother starting slave since it'll probably fail right away, unless you only do INSERT, never UPDATE/DELETE) 3) Get maatkit 4) Use mk-table-checksum --replicate on the master... this will lock your tables one at a time. 5) Use mk-table-sync --synctomaster on the slave to fix all the problems (that is, everything). The time to do this might not be much shorter than the 'correct' method of mysqldump --master-data or tar/mysqlhotcopy, but at least your tables would be only locked one at a time and not all at once (I think). Other than that, there's not a lot you can do. If you don't stop the db entirely, you'll at least still be able to read from it while you do your mysqldump / mysqlhotcopy / mk-table-checksum. Jake On Tue, Jan 6, 2009 at 4:04 AM, Claudio Nanni <claudio.na...@gmail.com> wrote: > All, Happy New Year, and let's hope somebody tries to stop the killing in > gaza. > > I need to setup a replication slave off a master that is currently > production and not stoppable or lockable(possibly). > > Do you have any idea on how to setup the slave with minimum or no impact on > the master? > > The database is about 80GB. > > Thanks > > C. > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
