Movatterモバイル変換

NDB Cluster supportsasynchronous 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 an NDB 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. (SeeChapter 19,Replication).

Normal (non-clustered) replication involves a source server and a replica server, the source being so named because operations and data to be replicated originate with it, and the replica being the recipient of these. In NDB 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 an NDB Cluster itself depends on theNDB storage engine for clustering functionality, it is not necessary to useNDB as the storage engine for the replica's copies of the replicated tables (seeReplication from NDB to other storage engines). However, for maximum availability, it is possible (and preferable) to replicate from one NDB Cluster to another, and it is this scenario that we discuss, as shown in the following figure:

Figure 25.10 NDB Cluster-to-Cluster Replication Layout

In this scenario, the replication process is one in which successive states of a source cluster are logged and saved to a replica 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 source and replica servers as replication servers or replication nodes, and the data flow or line of communication between them as areplication channel.

For information about performing point-in-time recovery with NDB Cluster and NDB Cluster Replication, seeSection 25.7.9.2, “Point-In-Time Recovery Using NDB Cluster Replication”.

NDB API replica status variables.  NDB API counters can provide enhanced monitoring capabilities on replica clusters. These counters are implemented as NDB statistics_replica status variables, as seen in the output ofSHOW STATUS, or in the results of queries against the Performance Schemasession_status orglobal_status table in amysql client session connected to a MySQL Server that is acting as a replica in NDB Cluster Replication. By comparing the values of these status variables before and after the execution of statements affecting replicatedNDB tables, you can observe the corresponding actions taken on the NDB API level by the replica, which can be useful when monitoring or troubleshooting NDB Cluster Replication.Section 25.6.14, “NDB API Statistics Counters and Variables”, provides additional information.

Replication from NDB to non-NDB tables.  It is possible to replicateNDB tables from an NDB Cluster acting as the replication source to tables using other MySQL storage engines such asInnoDB orMyISAM on a replicamysqld. This is subject to a number of conditions; seeReplication from NDB to other storage engines, andReplication from NDB to a nontransactional storage engine, for more information.