There is often confusion as to how it can be claimed that MySQL
Cluster delivers in-memory performance while also providing
durability (the “D” in ACID). This post explains how that can be
achieved as well as how to mix and match scalability, High
Availability and Durability.

MySQL Cluster deployment options

As an aside, the user can specify specific MySQL Cluster tables
or columns to be stored on disk rather than in memory – this is a
solution for extra capacity but you don’t need to take this
performance hit just to have the data persisted to disk. This
post focuses on the in-memory approach.

There is a great deal of flexibility in how you deploy MySQL
Cluster with in-memory data – allowing the user to decide which
features they want to make use of.

Until now PBXT has been ACId (with a lower-case d). This is soon
to change as I have had some weeks to work on a fully durable
version of the transactional engine (http://www.primebase.com/xt).

My first concern in making PBXT fully durable was to what extent
I would have to abandon the original "write-once" design. While
there are a number of ways to implement durability, the only
method used by databases (as far as I know) is the write-ahead
log.

The obvious advantage of this method is that all changes can be
flushed at once. However, this requires that all data be written
twice: once to the log and after that, to the database
itself.

My solution to this problem is a compromise, but I think it is a
good one. In a nutshell: short records are written twice, and
long records are written once. When it comes to durability, this
compromise, I …

Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.