Получите время последней глобальной контрольной точки (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 REPLICATION SOURCE TO, используемой для настройки этой реплики. Причина исключения таких эпох заключается в том, что строки в таблице mysql.ndb_apply_status, идентификаторы серверов которых совпадают в списке IGNORE_SERVER_IDS из инструкции CHANGE REPLICATION SOURCE TO, используемой для подготовки источника этой реплики, также считаются локальными серверами, в дополнение к серверу реплики. Вы можете получить этот список как Replicate_Ignore_Server_Ids из вывода инструкции SHOW REPLICA 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 REPLICATION SOURCE TO
      ->     SOURCE_LOG_FILE='@file',
      ->     SOURCE_LOG_POS=@pos;

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

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

mysqlR'> START REPLICA;