Получите время последней глобальной контрольной точки (GCP). То есть, вам необходимо определить последнее значение эпохи из таблицы ndb_apply_status на кластере реплик, что можно сделать с помощью следующего запроса:

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

В топологии циклической репликации, с источником и репликой, работающими на каждом узле, при использовании ndb_log_apply_status=1, эпохи NDB Cluster записываются в бинарные логи реплик. Это означает, что таблица ndb_apply_status содержит информацию для реплики на этом узле, а также для любого другого узла, который выступает в качестве реплики сервера источника репликации, работающего на этом узле.

В этом случае вам необходимо определить последнюю эпоху на этой реплике, исключая любые эпохи от других реплик в бинарном логе этой реплики, которые не были перечислены в параметрах IGNORE_SERVER_IDS в инструкции CHANGE MASTER TO, используемой для настройки этой реплики. Причина исключения таких эпох заключается в том, что строки в таблице mysql.ndb_apply_status, идентификаторы серверов которых совпадают в списке IGNORE_SERVER_IDS из инструкции CHANGE MASTER TO, используемой для подготовки источника этой реплики, также считаются исходящими от локальных серверов, помимо тех, у которых указан идентификатор собственного сервера реплики. Этот список можно получить как Replicate_Ignore_Server_Ids из вывода SHOW SLAVE STATUS. Предполагается, что вы получили этот список и подставили его вместо ignore_server_ids в представленном запросе, который, как и предыдущая версия запроса, выбирает наибольшую эпоху в переменную, названную @latest:

mysqlR'> SELECT @latest:=MAX(epoch)
      ->        FROM mysql.ndb_apply_status
      ->        WHERE server_id NOT IN (ignore_server_ids);

В некоторых случаях использование списка идентификаторов серверов для включения и server_id IN server_id_list в условии WHERE предыдущего запроса может быть проще или эффективнее (или и то, и другое).

Используя информацию, полученную из запроса, показанного в шаге 1, получите соответствующие записи из таблицы ndb_binlog_index на кластере источника.

Вы можете использовать следующий запрос для получения необходимых записей из таблицы ndb_binlog_index на источнике:

mysqlS'> SELECT
    ->     @file:=SUBSTRING_INDEX(next_file, '/', -1),
    ->     @pos:=next_position
    -> FROM mysql.ndb_binlog_index
    -> WHERE epoch = @latest;

Это записи, сохранённые на источнике с момента сбоя первичного канала репликации. Здесь используется пользовательская переменная @latest для представления значения, полученного на шаге 1. Конечно, один экземпляр mysqld не может напрямую получить доступ к пользовательским переменным, установленным на другом экземпляре сервера. Эти значения должны быть “вставлены” во второй запрос вручную или с помощью приложения.

Теперь можно синхронизировать вторичный канал, выполнив следующий запрос на сервере вторичной реплики:

mysqlR'> CHANGE MASTER TO
      ->     MASTER_LOG_FILE='@file',
      ->     MASTER_LOG_POS=@pos;

Здесь также используются пользовательские переменные (в данном случае @file и @pos) для представления значений, полученных на шаге 2 и применённых на шаге 3; на практике эти значения должны быть вставлены вручную или с помощью приложения, имеющего доступ к обоим серверам.

Теперь можно инициировать репликацию по вторичному каналу, выдав соответствующую инструкцию на вторичном сервере реплики mysqld:

mysqlR'> START SLAVE;