6.2. Replication Implementation Overview
MySQL replication is based on the master server keeping track of
all changes to your databases (updates, deletes, and so on) in its
binary logs. Therefore, to use replication, you must enable binary
logging on the master server. See Section 5.11.4, “The Binary Log”.
Each slave server receives from the master the saved updates that
the master has recorded in its binary log, so that the slave can
execute the same updates on its copy of the data.
It is extremely important to realize that the
binary log is simply a record starting from the fixed point in
time at which you enable binary logging. Any slaves that you set
up need copies of the databases on your master as they
existed at the moment you enabled binary logging on the
master. If you start your slaves with databases that
are not in the same state as those on the master when the binary
log was started, your slaves are quite likely to fail.
One way to copy the master's data to the slave is to use the
LOAD DATA FROM MASTER statement. However,
LOAD DATA FROM MASTER works only if all the
tables on the master use the MyISAM storage
engine. In addition, this statement acquires a global read lock,
so no updates on the master are possible while the tables are
being transferred to the slave. When we implement lock-free hot
table backup, this global read lock will no longer be necessary.
Due to these limitations, we recommend that at this point you use
LOAD DATA FROM MASTER only if the dataset on
the master is relatively small, or if a prolonged read lock on the
master is acceptable. Although the actual speed of LOAD
DATA FROM MASTER may vary from system to system, a good
rule of thumb for how long it takes is 1 second per 1MB of data.
This is a rough estimate, but you should find it fairly accurate
if both master and slave are equivalent to 700MHz Pentium CPUs in
performance and are connected through a 100Mbps network.
After the slave has been set up with a copy of the master's data,
it connects to the master and waits for updates to process. If the
master fails, or the slave loses connectivity with your master,
the slave keeps trying to connect periodically until it is able to
resume listening for updates. The
--master-connect-retry option controls the retry
interval. The default is 60 seconds.
Each slave keeps track of where it left off when it last read from
its master server. The master has no knowledge of how many slaves
it has or which ones are up to date at any given time.
