In a more complete example scenario, we envision two replication channels to provide redundancy and thereby guard against possible failure of a single replication channel. This requires a total of four replication servers, two source servers on the source cluster and two replica servers on the replica cluster. For purposes of the discussion that follows, we assume that unique identifiers are assigned as shown here:
Table 7.5 NDB Cluster replication servers described in the text
Server ID | Description |
---|---|
1 | Source - primary replication channel (S) |
2 | Source - secondary replication channel (S') |
3 | Replica - primary replication channel (R) |
4 | replica - secondary replication channel (R') |
Setting up replication with two channels is not radically
different from setting up a single replication channel. First, the
mysqld processes for the primary and secondary
replication source servers must be started, followed by those for
the primary and secondary replicas. The replication processes can
be initiated by issuing the START
SLAVE
statement on each of the replicas. The commands
and the order in which they need to be issued are shown here:
Start the primary replication source:
shellS> mysqld --ndbcluster --server-id=1 \ --log-bin &
Start the secondary replication source:
shellS'> mysqld --ndbcluster --server-id=2 \ --log-bin &
Start the primary replica server:
shellR> mysqld --ndbcluster --server-id=3 \ --skip-slave-start &
Start the secondary replica server:
shellR'> mysqld --ndbcluster --server-id=4 \ --skip-slave-start &
Finally, initiate replication on the primary channel by executing the
START SLAVE
statement on the primary replica as shown here:mysqlR> START SLAVE;
WarningOnly the primary channel must be started at this point. The secondary replication channel needs to be started only in the event that the primary replication channel fails, as described in Section 7.8, “Implementing Failover with NDB Cluster Replication”. Running multiple replication channels simultaneously can result in unwanted duplicate records being created on the replicas.
As mentioned previously, it is not necessary to enable binary logging on the replicas.