|
Michael McConnell wrote:
Paul, I see a few problems in the configuration you described.
You explained that I can kill the MySQL on the Master, tar it up, copy the
data to the Slave and activate it as the Slave. Unfortunately this is not
how MySQL works. MySQL requires that the Master and Slave be identical data
files, *IDENTICAL* that means the Master (tar file) cannot change before the
Slave comes online.
Well I suppose there was an extra step that I left out (because it
doesn't affect the amount of downtime). The complete migration steps
would be:
1. Modify my.cnf file to turn on replication of the master server. This
is done while the master mysql daemon is still running with the previous
config in memory.
2. shutdown the mysql daemon via kill.
3. tar up the data.
4. start up the mysql daemon. This will activate replication on the
master and cause it to start logging all changes for replication since
the time of the snapshot in step 3.
At this point downtime is only as long as it takes you to do steps 2, 3,
and 4.
5. copy the snapshot to a slave server and active replication in the
my.cnf on the slave server as both a master and a slave.
6. start up the slave daemon. at this time the slave will connect to the
master and catch up to any of the changes that took place since the
snapshot.
So as you see, the data can change on the master before the slave comes
online. The data just can't change between when you make the snapshot
and when the master daemon comes up configured for replication as a master.
--
=======================================================================
Paul J. Baker Internet Systems Developer
pbaker@xxxxxxxxxxxxxxx Where2GetIt.com
phone 847-498-0111x234
fax 847-480-7422
=======================================================================
|
