Получите время последней глобальной контрольной точки (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;