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
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
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.
On Tue, Jan 6, 2009 at 4:04 AM, Claudio Nanni <claudio.nanni@stripped> wrote:
> All, Happy New Year, and let's hope somebody tries to stop the killing in
> 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.