Oracle 5.0 Reference Manual page 2925

2. On the slave, issue the following statement, where the arguments to the
MASTER_POS_WAIT()
step:
mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);
The statement blocks until the slave reaches the specified log file and position. At that
SELECT
point, the slave is in synchrony with the master and the statement returns.
3. On the master, issue the following statement to enable the master to begin processing updates
again:
mysql> UNLOCK TABLES;
B.13.5: What issues should I be aware of when setting up two-way replication?
MySQL replication currently does not support any locking protocol between master and slave to
guarantee the atomicity of a distributed (cross-server) update. In other words, it is possible for client
A to make an update to co-master 1, and in the meantime, before it propagates to co-master 2, client
B could make an update to co-master 2 that makes the update of client A work differently than it did
on co-master 1. Thus, when the update of client A makes it to co-master 2, it produces tables that
are different from what you have on co-master 1, even after all the updates from co-master 2 have
also propagated. This means that you should not chain two servers together in a two-way replication
relationship unless you are sure that your updates can safely happen in any order, or unless you take
care of mis-ordered updates somehow in the client code.
You should also realize that two-way replication actually does not improve performance very much (if
at all) as far as updates are concerned. Each server must do the same number of updates, just as you
would have a single server do. The only difference is that there is a little less lock contention because
the updates originating on another server are serialized in one slave thread. Even this benefit might be
offset by network delays.
B.13.6: How can I use replication to improve performance of my system?
Set up one server as the master and direct all writes to it. Then configure as many slaves as you have
the budget and rackspace for, and distribute the reads among the master and the slaves. You can
also start the slaves with the
delay-key-write=ALL
slave uses nontransactional
transactional overhead.
B.13.7: What should I do to prepare client code in my own applications to use performance-
enhancing replication?
See the guide to using replication as a scale-out solution,
Out".
B.13.8: When and how much can MySQL replication improve the performance of my system?
MySQL replication is most beneficial for a system that processes frequent reads and infrequent writes.
In theory, by using a single-master/multiple-slave setup, you can scale the system by adding more
slaves until you either run out of network bandwidth, or your update load grows to the point that the
master cannot handle it.
To determine how many slaves you can use before the added benefits begin to level out, and how
much you can improve performance of your site, you must know your query patterns, and determine
empirically by benchmarking the relationship between the throughput for reads and writes on a typical
master and a typical slave. The example here shows a rather simplified calculation of what you can
get with replication for a hypothetical system. Let
writes per second, respectively.
MySQL 5.0 FAQ: Replication
[966] function are the replication coordinate values obtained in the previous
[1236],
--skip-innodb
[406] options to get speed improvements on the slave end. In this case, the
tables instead of
MyISAM
2905
--low-priority-updates
tables to get more speed by eliminating
InnoDB
Section 16.3.3, "Using Replication for Scale-
and denote the number of reads and
reads writes
[414], and
--