MySQL replication is based on the
server keeping track of all changes to your database (updates, deletes, etc) in
the binary log. and the slave server(s) reading the saved queries from the
master server's binary log so that the slave can execute the same queries on
its copy of the data.
It is very important to realize that
the binary log is simply a record starting from a fixed point in time (the
moment you enable binary logging). Any slaves which you set up will need copies
of all the data from your master as it existed the moment that you enabled
binary logging on the master. If you start your slaves with data that doesn't
agree with what was on the master when the binary log was started, your slaves
may fail.
A future version (4.0) of MySQL will
remove the need to keep a (possibly large) snapshot of data for new slaves that
you might wish to set up through the live backup functionality with no locking
required. However, at this time, it is necessary to block all writes either
with a global read lock or by shutting down the master while taking a snapshot.
Once a slave is properly configured
and running, it will simply connect to the master and wait for updates to
process. If the master goes away or the slave loses connectivity with your
master, it will keep trying to connect every master-connect-retry seconds until
it is able to reconnect and resume listening for updates.
Each slave keeps track of where it
left off. The master server has no knowledge of how many slaves there are or
which ones are up-to-date at any given time.
No comments:
Post a Comment