17.6 MySQL Cluster Replication

17.6.1 MySQL Cluster Replication: Abbreviations and Symbols
17.6.2 General Requirements for MySQL Cluster Replication
17.6.3 Known Issues in MySQL Cluster Replication
17.6.4 MySQL Cluster Replication Schema and Tables
17.6.5 Preparing the MySQL Cluster for Replication
17.6.6 Starting MySQL Cluster Replication (Single Replication Channel)
17.6.7 Using Two Replication Channels for MySQL Cluster Replication
17.6.8 Implementing Failover with MySQL Cluster Replication
17.6.9 MySQL Cluster Backups With MySQL Cluster Replication
17.6.10 MySQL Cluster Replication: Multi-Master and Circular Replication
17.6.11 MySQL Cluster Replication Conflict Resolution

Previous to MySQL 5.1.6, asynchronous replication, more usually referred to simply as replication, was not available when using MySQL Cluster. MySQL 5.1.6 introduces master-slave replication of this type for MySQL Cluster databases. This section explains how to set up and manage a configuration wherein 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 16, 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 NDB storage engine for clustering functionality, it is not necessary to use 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:

Figure 17.13 MySQL Cluster-to-Cluster Replication Layout

MySQL Cluster-to-Cluster Replication Layout

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 binlog 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 replication channel.

For information about performing point-in-time recovery with MySQL Cluster and MySQL Cluster Replication, see Section, “Point-In-Time Recovery Using MySQL Cluster Replication”.

NDB API _slave status variables.  Beginning with MySQL Cluster NDB 7.0.22 and MySQL Cluster NDB 7.1.11, NDB API counters provide enhanced monitoring capabilities on MySQL Cluster replication slaves. These are implelemented as NDB statistics _slave status variables, as seen in the output of SHOW STATUS, or in the results of queries against the SESSION_STATUS or GLOBAL_STATUS 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 Cluster Replication. Section 17.5.15, “NDB API Statistics Counters and Variables”, provides additional information.

Replication from NDB to non-NDB tables.  It is possible to replicate NDB tables from a MySQL Cluster acting as the master to tables using other MySQL storage engines such as InnoDB or MyISAM on a slave mysqld. This is subject to a number of conditions; see Replication from NDB to other storage engines, and Replication from NDB to a nontransactional storage engine, for more information.