17.6.8. Реализация Failover с MySQL Cluster Replication

Когда основной процесс репликации Кластера перестал работать, возможно переключиться к вторичному каналу репликации. Следующая процедура описывает шаги, требуемые выполнять это.

Получите время новой глобальной контрольной точки (GCP). Таким образом, Вы должны определить новую эпоху от ndb_apply_status таблица на ведомом кластере, который может быть найден, используя следующий запрос:
```
mysqlS'> SELECT @latest:=MAX(epoch)      ->        FROM mysql.ndb_apply_status;
```
Используя информацию, полученную из запроса, показанного в Шаге 1, получите соответствующие записи из ndb_binlog_index таблица на основном кластере.

В MySQL Cluster NDB 7.3, можно использовать следующий запрос, чтобы получить необходимые записи от ведущего устройства ndb_binlog_index таблица:
```
mysqlM'> SELECT      ->     @file:=SUBSTRING_INDEX(next_file,
                    '/', -1),      ->     @pos:=next_position      -> FROM mysql.ndb_binlog_index      -> WHERE epoch = @latest      -> ORDER BY epoch ASC LIMIT 1;
```
Они - записи, на которых экономят ведущее устройство начиная с отказа основного канала репликации. Мы использовали пользовательскую переменную @latest здесь представлять значение, полученное в Шаге 1. Конечно, для одного mysqld экземпляра не возможно получить доступ к пользовательскому набору переменных на другом экземпляре сервера непосредственно. Эти значения должны быть "включены" к второму запросу вручную или в коде программы.

Важный

Следует гарантировать, что ведомое устройство mysqld запускается с --slave-skip-errors=ddl_exist_errors перед выполнением START SLAVE. Иначе, репликация может остановиться с двойными ошибками DDL.
Теперь возможно синхронизировать вторичный канал, выполняя следующий запрос на вторичном ведомом сервере:
```
mysqlS'> CHANGE MASTER TO      ->     MASTER_LOG_FILE='@file',      ->     MASTER_LOG_POS=@pos;
```
Снова мы использовали пользовательские переменные (в этом случае @file и @pos) представлять значения, полученные в Шаге 2 и примененный в Шаге 3; практически эти значения должны быть вставлены вручную или код программы использования, который может получить доступ к обоим из включенных серверов.

Отметить

@file строковое значение такой как '/var/log/mysql/replication-master-bin.00001', и так должен быть заключен в кавычки когда использующийся в SQL или коде программы. Однако, значение, представленное @pos не должен быть заключен в кавычки. Хотя MySQL обычно пытается преобразовать строки в числа, этот случай является исключением.
Можно теперь инициировать репликацию на вторичном канале, давая соответствующую команду на вторичном ведомом устройстве mysqld:
```
mysqlS'> START SLAVE;
```

Как только вторичный канал репликации является активным, можно исследовать отказ основных восстановлений и восстановлений эффекта. Точные действия, требуемые сделать, это будет зависеть от причин который основной отказавший канал.

Предупреждение

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

Если отказ ограничивается единственным сервером, он должен (в теории), возможны тиражироваться от M к S', или от M' к S; однако, это еще не было протестировано.