Databases Reference
In-Depth Information
the data for durability. NDB operates on the same principle. The cluster's durability as
a whole is not reduced; only the local durability is reduced. In addition, it supports
parallel (multithreaded) replication at the row level, so multiple CPU cores can be used
to apply write sets. These characteristics combine to make Percona XtraDB Cluster
attractive in cloud computing environments, where disks and CPUs are usually slower
than normal.
The cluster implements autoincrementing keys with
auto_increment_offset
and
auto
_increment_increment
so that nodes won't generate conflicting values. Locking is gen-
erally the same as it is in standard InnoDB. It uses optimistic concurrency control.
Changes are serialized and transmitted between nodes at transaction commit, with a
certification process so that if there is a conflicting update, someone has to lose. As a
result, if many nodes are changing the same rows simultaneously, there can be lots of
deadlocks and rollbacks.
Percona XtraDB Cluster provides high availability by keeping the nodes online as long
as they form a quorum. If nodes discover that they are not part of a quorum, they are
ejected from the cluster, and they must resync before joining the cluster again. As a
result, the cluster can't handle split-brain scenarios; it will stop if that happens. When
a node fails in a two-node cluster, the remaining node isn't a quorum and will stop
functioning, so in practice you need at least three nodes to have a high-availability
cluster.
Percona XtraDB Cluster has lots of benefits:
• It provides transparent clustering based on InnoDB, so there's no need to move to
another technology such as NDB, which is a whole different beast to learn and
administer.
• It provides real high availability, with all nodes equal and ready for reads and writes
at all times. In contrast, MySQL's built-in asynchronous or semisynchronous rep-
lication must have one master, can't guarantee that your data is replicated, and
can't guarantee that replicas are up-to-date and ready for reads or to be promoted
to master.
• It protects you against data loss when a node fails. In fact, because all nodes have
all the data, you can lose every node but one and still not lose the data (even if the
cluster has a split brain and stops working). This is different from NDB, where the
data is partitioned across node groups and some data can be lost if all servers in a
node group are lost.
• Replicas cannot fall behind, because write sets are propagated to and certified on
every node in the cluster before the transaction commits.
• Because it uses row-based log events to apply changes to replicas, applying write
sets can be less expensive than generating them, just as with normal row-based
replication. This, combined with multithreaded application of write sets, can make
its replication more scalable than MySQL replication.
