NDB Cluster Backups With NDB Cluster Replication 3. Now it is possible to synchronize the secondary channel by running the following query on the secondary replica server: mysql R’ >  CHANGE MASTER TO -> MASTER_LOG_FILE=’@file’, -> MASTER_LOG_POS=@pos; mysql R’ >  CHANGE REPLICATION SOURCE TO -> SOURCE_LOG_FILE=’@file’, -> SOURCE_LOG_POS=@pos; In MySQL 8.0.23 and later, you can also use the statement shown here: Again we have employed user variables (in this case  @file  and  @pos ) to represent the values obtained in Step 2 and applied in Step 3; in practice these values must be inserted manually or using an application that can access both of the servers involved. Note @file  is a string value such as  ’/var/log/mysql/replication-source- bin.00001’ , and so must be quoted when used in SQL or application code. However, the value represented by  @pos  must  not  be quoted. Although MySQL normally attempts to convert strings to numbers, this case is an exception. In MySQL 8.0.22 or later, you can also use the following statement: mysql R’ >  START SLAVE; mysql R’ >  START REPLICA; • Method A.   This method requires that the cluster backup process was previously enabled on the source server, prior to starting the replication process. This can be done by including the following line in a  [mysql_cluster]  section in the  my.cnf file , where  management_host  is the 1. There are two different methods by which the backup may be started. 4630 This section discusses making backups and restoring from them using NDB Cluster replication. We assume that the replication servers have already been configured as covered previously (see Section 23.6.5, “Preparing the NDB Cluster for Replication” , and the sections immediately following). This having been done, the procedure for making a backup and then restoring from it is as follows: 23.6.9 NDB Cluster Backups With NDB Cluster Replication Warning 4. You can now initiate replication on the secondary channel by issuing the appropriate command on the secondary replica  mysqld : Once the secondary replication channel is active, you can investigate the failure of the primary and effect repairs. The precise actions required to do this depend upon the reasons for which the primary channel failed. The secondary replication channel is to be started only if and when the primary replication channel has failed. Running multiple replication channels simultaneously can result in unwanted duplicate records being created on the replicas. If the failure is limited to a single server, it should in theory be possible to replicate from  S  to  R’ , or from  S’ to  R .