[+/-]
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
    NDBCLUSTER storage engine for
    clustering functionality, it is not necessary to use the Cluster
    storage engine on the slave. However, for maximum availability, it
    is possible to replicate from one MySQL Cluster to another, and it
    is this type of configuration 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
    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 via 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 17.6.9.2, “Point-In-Time Recovery Using MySQL Cluster Replication”.

User Comments
Add your own comment.