MySQL Cluster supports asynchronous replication, more usually referred to simply as “replication”. This section explains how to set up and manage a configuration in which one group of computers operating as a MySQL Cluster replicates to a second computer or group of computers. We assume some familiarity on the part of the reader with standard MySQL replication as discussed elsewhere in this Manual. (See Chapter 17, Replication).
Normal (non-clustered) replication involves a “master”
server and a “slave” server, the master being the
source of the operations and data to be replicated and the slave
being the recipient of these. In MySQL Cluster, replication is
conceptually very similar but can be more complex in practice, as it
may be extended to cover a number of different configurations
including replicating between two complete clusters. Although a
MySQL Cluster itself depends on the
storage engine for clustering functionality, it is not necessary to
NDB as the storage engine for the
slave's copies of the replicated tables (see
Replication from NDB to other storage engines).
However, for maximum availability, it is possible (and preferable)
to replicate from one MySQL Cluster to another, and it is this
scenario that we discuss, as shown in the following figure:
In this scenario, the replication process is one in which successive
states of a master cluster are logged and saved to a slave cluster.
This process is accomplished by a special thread known as the NDB
binary log injector thread, which runs on each MySQL server and
produces a binary log (
binlog). This thread
ensures that all changes in the cluster producing the binary
log—and not just those changes that are effected through the
MySQL Server—are inserted into the binary log with the correct
serialization order. We refer to the MySQL replication master and
replication slave servers as replication servers or replication
nodes, and the data flow or line of communication between them as a
For information about performing point-in-time recovery with MySQL Cluster and MySQL Cluster Replication, see Section 220.127.116.11, “Point-In-Time Recovery Using MySQL Cluster Replication”.
NDB API _slave status variables.
NDB API counters can provide enhanced monitoring capabilities on
MySQL Cluster replication slaves. These are implemented as NDB
_slave status variables, as seen in
the output of
SHOW STATUS, or in
the results of queries against the
table in a mysql client session connected to a
MySQL Server that is acting as a slave in MySQL Cluster
Replication. By comparing the values of these status variables
before and after the execution of statements affecting replicated
NDB tables, you can observe the
corresponding actions taken on the NDB API level by the slave,
which can be useful when monitoring or troubleshooting MySQL
Section 18.5.15, “NDB API Statistics Counters and Variables”, provides
Replication from NDB to non-NDB tables.
It is possible to replicate
tables from a MySQL Cluster acting as the master to tables using
other MySQL storage engines such as
MyISAM on a slave
mysqld. This is subject to a number of
Replication from NDB to other storage engines, and
Replication from NDB to a nontransactional storage engine,
for more information.