Вы можете указать реплике изменить источник на новый, используя оператор CHANGE REPLICATION SOURCE TO. Реплика не проверяет, совместимы ли базы данных на источнике с базами данных на реплике; она просто начинает читать и выполнять события из указанных координат в бинарном журнале нового источника. В ситуации восстановления все серверы в группе, как правило, выполняют одни и те же события из одного и того же бинарного файла журнала, поэтому изменение источника событий не должно повлиять на структуру или целостность базы данных, при условии, что вы будете осторожны при внесении изменений.

Реплики должны запускаться с включённым бинарным журналированием (опция --log-bin), что является значением по умолчанию. Если вы не используете GTID для репликации, то реплики также должны запускаться с --log-replica-updates=OFF (журналирование обновлений реплик по умолчанию). Таким образом, реплика готова стать источником без перезапуска реплики mysqld. Предполагается, что у вас есть структура, показанная на рисунке 19.4 «Избыточность с использованием репликации, начальная структура».

Рисунок 19.4 Избыточность с использованием репликации, начальная структура

На этом рисунке Source содержит базу данных источника, Replica* являются репликами, а машины Web Client выполняют чтение и запись в базу данных. Клиенты веб-приложений, выполняющие только чтение (и которые обычно подключаются к репликам), не показаны, так как им не нужно переключаться на новый сервер в случае сбоя. Более подробный пример структуры репликации с масштабированием по чтению/записи см. в разделе 19.4.5 «Использование репликации для масштабирования».

Каждая MySQL-реплика (Replica 1, Replica 2 и Replica 3) — это реплика, запущенная с включённым бинарным журналированием и --log-replica-updates=OFF. Поскольку обновления, полученные репликой от источника, не записываются в бинарный журнал, когда --log-replica-updates=OFF указано, бинарный журнал на каждой реплике изначально пуст. Если по какой-либо причине Source станет недоступным, вы можете выбрать одну из реплик в качестве нового источника. Например, если вы выберете Replica 1, все Web Clients должны быть перенаправлены на Replica 1, который запишет обновления в свой бинарный журнал. Replica 2 и Replica 3 должны затем реплицировать данные из Replica 1.

Причина запуска реплики с --log-replica-updates=OFF заключается в предотвращении получения репликами обновлений дважды в случае, если вы заставите одну из реплик стать новым источником. Если Replica 1 имеет --log-replica-updates включенным, что является значением по умолчанию, то он записывает все обновления, которые получает от Source, в свой собственный бинарный журнал. Это означает, что когда Replica 2 изменяет источник с Source на Replica 1, он может получить обновления от Replica 1, которые он уже получил от Source.

Убедитесь, что все реплики обработают все инструкции в своём релейном журнале. На каждой реплике выполните STOP REPLICA IO_THREAD, а затем проверьте вывод SHOW PROCESSLIST, пока не увидите Has read all relay log. Когда это будет верно для всех реплик, их можно перенастроить на новую конфигурацию. На реплике Replica 1, которая должна стать источником, выполните STOP REPLICA и RESET BINARY LOGS AND GTIDS.

На других репликах Replica 2 и Replica 3 используйте STOP REPLICA и CHANGE REPLICATION SOURCE TO SOURCE_HOST='Replica1' (где 'Replica1' представляет реальное имя хоста Replica 1). Для использования CHANGE REPLICATION SOURCE TO, добавьте всю информацию о подключении к Replica 1 из Replica 2 или Replica 3 (user, password, port). При выполнении инструкции в этом случае нет необходимости указывать имя бинарного файла журнала Replica 1 или позицию журнала для чтения, так как по умолчанию используются первый бинарный файл журнала и позиция 4. Наконец, выполните START REPLICA на Replica 2 и Replica 3.

После того, как новая конфигурация репликации будет установлена, необходимо указать каждой Web Client направить свои инструкции на Replica 1. С этого момента все обновления, отправленные Web Client в Replica 1, записываются в бинарный журнал Replica 1, который теперь содержит все обновления, отправленные в Replica 1 с момента недоступности Source.

Результирующая структура сервера показана на рисунке 19.5 «Избыточность с использованием репликации после отказа источника».

Рисунок 19.5 Избыточность с использованием репликации после отказа источника

Когда Source снова станет доступным, вы должны сделать его репликой Replica 1. Для этого на Source выполните оператор CHANGE REPLICATION SOURCE TO, такой же, как тот, что был выполнен на Replica 2 и Replica 3 ранее. Затем Source становится репликой Replica 1 и получает пропущенные Web Client записи, которые были потеряны во время его простоя.

Чтобы снова сделать Source источником, используйте описанную выше процедуру, как если бы Replica 1 был недоступен, а Source должен быть новым источником. Во время этой процедуры не забудьте запустить RESET BINARY LOGS AND GTIDS на Source перед тем, как сделать Replica 1, Replica 2 и Replica 3 репликами Source. В противном случае реплики могут получить устаревшие записи от приложений Web Client, относящиеся к периоду до момента недоступности Source.

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

Один из способов информировать приложения о местоположении источника — это иметь динамическую запись DNS для хоста источника. С BIND вы можете использовать nsupdate для динамического обновления DNS.