Oracle 5.0 Reference Manual page 2924

• B.13.10: [2906] How do I tell whether a master server is using statement-based or row-based binary
logging format?
• B.13.11: [2907] How do I tell a slave to use row-based replication?
• B.13.12: [2907] How do I prevent
machines?
• B.13.13: [2907] Does replication work on mixed operating systems (for example, the master runs on
Linux while slaves run on Mac OS X and Windows)?
• B.13.14: [2907] Does replication work on mixed hardware architectures (for example, the master
runs on a 64-bit machine while slaves run on 32-bit machines)?
Questions and Answers
B.13.1: Must the slave be connected to the master all the time?
No, it does not. The slave can go down or stay disconnected for hours or even days, and then
reconnect and catch up on updates. For example, you can set up a master/slave relationship over a
dial-up link where the link is up only sporadically and for short periods of time. The implication of this is
that, at any given time, the slave is not guaranteed to be in synchrony with the master unless you take
some special measures.
To ensure that catchup can occur for a slave that has been disconnected, you must not remove
binary log files from the master that contain information that has not yet been replicated to the slaves.
Asynchronous replication can work only if the slave is able to continue reading the binary log from the
point where it last read events.
B.13.2: Must I enable networking on my master and slave to enable replication?
Yes, networking must be enabled on the master and slave. If networking is not enabled, the slave
cannot connect to the master and transfer the binary log. Check that the
option has not been enabled in the configuration file for either server.
B.13.3: How do I know how late a slave is compared to the master? In other words, how do I
know the date of the last statement replicated by the slave?
Check the
Seconds_Behind_Master
Section 16.1.3.1, "Checking Replication
When the slave SQL thread executes an event read from the master, it modifies its own time to the
event timestamp. (This is why
PROCESSLIST, the number of seconds displayed for the slave SQL thread is the number of seconds
between the timestamp of the last replicated event and the real time of the slave machine. You can use
this to determine the date of the last replicated event. Note that if your slave has been disconnected
from the master for one hour, and then reconnects, you may immediately see large
as 3600 for the slave SQL thread in
statements that are one hour old. See
B.13.4: How do I force the master to block updates until the slave catches up?
Use the following procedure:
1. On the master, execute these statements:
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
Record the replication coordinates (the current binary log file name and position) from the output of
the statement.
SHOW
MySQL 5.0 FAQ: Replication
and
GRANT REVOKE
column in the output from
Status".
is well replicated.) In the
TIMESTAMP
PROCESSLIST. This is because the slave is executing
SHOW
Section 16.2.1, "Replication Implementation
2904
statements from replicating to slave
skip-networking
SHOW SLAVE
column in the output of
Time
[421]
STATUS. See
SHOW
values such
Time
Details".