The first day of the first MySQL Connect
conference is done. It's been a busy day! Many
attendees are interested in the new MySQL Server 5.6 release, but
of course MySQL Cluster is the main draw here. After a
session from Oracle on the new features in 7.2, and early access
features in 7.3, I attended Santo Leto's
MySQL Cluster 'hands on lab'. Despite having started more
clusters than most, it felt like a new and exciting experience
installing and running my cluster alongside everyone else.
The lab machines had some networking issues, but with Santo's
help we seamlessly failed-over to some downloads he'd prepared
earlier - very professional!
Afterwards it was my turn to talk on the subject of MySQL Cluster
performance. The quality of the questions was impressive -
there seems to be a very capable crowd in San Francisco this …
tldr; A single MySQL Cluster prioritises Consistency in Network
partition events. Asynchronously replicating MySQL Clusters
prioritise Availability in Network partition events.
I was recently asked about the relationship between MySQL Cluster
and the CAP theorem. The CAP theorem is often described as
a pick two out of three problem, such as choosing from good,
cheap, fast. You can have any two, but you can't have all three.
For CAP the three qualities are 'Consistency', 'Availability' and
'Partition tolerance'. CAP states that in a system with data
replicated over a network only two of these three qualities can
be maintained at once, so which two does MySQL Cluster
provide?
Standard 'my interpretation of CAP' section
Everyone who discusses CAP like to rehash it, and I'm no
exception. …
As always, I am a little late, but I want to jump on the
bandwagon and mention the recent MySQL Cluster milestone of
passing 1 billion queries per minute. Apart from echoing
the arbitrarily large ransom demand of Dr Evil, what does this
mean?
Obviously 1 billion is only of interest to us humans as we
generally happen to have 10 fingers, and seem to name multiples
in steps of 10^3 for some reason. Each processor involved in this benchmark
is clocked at several billion cycles per second, so a single
billion is not so vast or fast.
Measuring over a minute also feels unnatural for a computer
performance benchmark - we are used to lots of things happening
every second! A minute is a long time in silicon.
What's more, these …
Most software people are aware of the ACID
acronym coined by Jim Gray. With the growth of the web and open
source, the scaling and complexity constraints imposed on DBMS
implementations supporting ACID are more visible, and new (or at
least new terms for known) compromises and tradeoffs are being
discussed widely. The better known NoSQL
systems are giving insight by example into particular choices of
tradeoffs.
Working at MySQL, I have often been surprised at the variety of
potential alternatives when implementing a DBMS, and the number
of applications which don't need the full set of ACID letters in
the strictest form. The original MySQL storage engine, MyISAM
is one of the first and most successful examples of an 'ACID
remix'. The people …