Databases Reference
In-Depth Information
catches up to the desired point on the master. Alternatively, you can use a repli-
cation heartbeat to check for up-to-dateness; see
Chapter 10
for more on this.
Write synchronization
You can also use
MASTER_POS_WAIT()
to make sure your writes actually reach one
or more replicas. If your application needs to emulate synchronous replication to
guarantee data safety, it can cycle between each replica, running
MASTER_
POS_WAIT()
on each. This creates a “synchronization barrier” that can take a long
time to pass if any of the replicas is far behind in replication, so it's a good idea to
use it only when absolutely necessary. (You can also wait until just one replica
receives the event if your goal is only to ensure that some replica has the event.
MySQL 5.5 adds semisynchronous replication, which supports this technique
natively.)
Summary
Scaling MySQL correctly is a bit less glamorous than it often seems. The right way to
scale isn't to build the next Facebook architecture from day one. A better strategy is to
do what's clearly needed for your application, and plan ahead so that if you do grow
very rapidly, your success will finance whatever steps are necessary to meet the demand.
It is valuable to have a mathematical definition of scalability, just as it's useful to have
a precise concept of performance, and the Universal Scalability Law can provide a
helpful framework. Knowing that systems fail to scale linearly because of costs such as
serialization and crosstalk can help you avoid building those problems into your ap-
plication. At the same time, many scalability problems aren't mathematical; they may
be due to problems within the organization, such as lack of teamwork or other less
concrete issues. Dr. Neil J. Gunther's book
Guerrilla Capacity Planning
and Eliyahu
M. Goldratt's book
The Goal
are good reading for anyone interested in understanding
more about why systems don't scale.
In terms of MySQL scalability strategies, the typical application that grows very large
usually moves from a single server, to a scale-out architecture with read replicas, to
sharding and/or functional partitioning. We disagree with those who advocate a “shard
early, shard often” approach for every application. It's complicated and expensive, and
many applications will never need it. It is perfectly legitimate to bide your time and see
what happens with new hardware, new versions of MySQL, or new developments in
MySQL Cluster, and even to evaluate a proprietary system such as Clustrix. Sharding
is a hand-built clustering system, after all, and it's a good idea not to reinvent the wheel
if you don't need to.
Where there are multiple servers, there are problems with consistency and atomicity.
The most common problems we see are lack of session consistency (posting a comment
on a website, refreshing the page, and not seeing the comment you just posted) and
failures when telling the application which servers are readable and writable. The latter
