There are two different methods by which the backup may be started.

Copy the cluster backup files to the replica that is being brought on line. Each system running an ndbd process for the source cluster has cluster backup files located on it, and all of these files must be copied to the replica to ensure a successful restore. The backup files can be copied into any directory on the computer where the replica's management host resides, as long as the MySQL and NDB binaries have read permissions in that directory. In this case, we assume that these files have been copied into the directory /var/BACKUPS/BACKUP-1.

While it is not necessary that the replica cluster have the same number of data nodes as the source, it is highly recommended this number be the same. It is necessary that the replication process is prevented from starting when the replica server starts. You can do this by starting the replica with --skip-replica-start.

Create any databases on the replica cluster that are present on the source cluster and that are to be replicated.

Reset the replica cluster using this statement in the mysql client:

mysqlR> RESET REPLICA;

You can now start the cluster restoration process on the replica using the ndb_restore command for each backup file in turn. For the first of these, it is necessary to include the -m option to restore the cluster metadata, as shown here:

shellR> ndb_restore -c replica_host:port -n node-id \
        -b backup-id -m -r dir

dir is the path to the directory where the backup files have been placed on the replica. For the ndb_restore commands corresponding to the remaining backup files, the -m option should not be used.

For restoring from a source cluster with four data nodes (as shown in the figure in Section 25.7, “NDB Cluster Replication”) where the backup files have been copied to the directory /var/BACKUPS/BACKUP-1, the proper sequence of commands to be executed on the replica might look like this:

shellR> ndb_restore -c replica-host:1186 -n 2 -b 1 -m \
        -r ./var/BACKUPS/BACKUP-1
shellR> ndb_restore -c replica-host:1186 -n 3 -b 1 \
        -r ./var/BACKUPS/BACKUP-1
shellR> ndb_restore -c replica-host:1186 -n 4 -b 1 \
        -r ./var/BACKUPS/BACKUP-1
shellR> ndb_restore -c replica-host:1186 -n 5 -b 1 -e \
        -r ./var/BACKUPS/BACKUP-1

Now you need to obtain the most recent epoch from the ndb_apply_status table on the replica (as discussed in Section 25.7.8, “Implementing Failover with NDB Cluster Replication”):

mysqlR> SELECT @latest:=MAX(epoch)
        FROM mysql.ndb_apply_status;

Using @latest as the epoch value obtained in the previous step, you can obtain the correct starting position @pos in the correct binary log file @file from the mysql.ndb_binlog_index table on the source. The query shown here gets these from the Position and File columns from the last epoch applied before the logical restore position:

mysqlS> SELECT
     ->     @file:=SUBSTRING_INDEX(File, '/', -1),
     ->     @pos:=Position
     -> FROM mysql.ndb_binlog_index
     -> WHERE epoch > @latest
     -> ORDER BY epoch ASC LIMIT 1;

In the event that there is currently no replication traffic, you can get similar information by running SHOW BINARY LOG STATUS on the source and using the value shown in the Position column of the output for the file whose name has the suffix with the greatest value for all files shown in the File column. In this case, you must determine which file this is and supply the name in the next step manually or by parsing the output with a script.

Using the values obtained in the previous step, you can now issue the appropriate in the replica's mysql client. Use the following CHANGE REPLICATION SOURCE TO statement:

mysqlR> CHANGE REPLICATION SOURCE TO
     ->     SOURCE_LOG_FILE='@file',
     ->     SOURCE_LOG_POS=@pos;

Now that the replica knows from what point in which binary log file to start reading data from the source, you can cause the replica to begin replicating with this statement:

mysqlR> START REPLICA;