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

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

Рисунок 16.4 Резервирование с помощью репликации, начальная структура

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

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

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

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

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

Наконец, выполните START SLAVE на Replica 2 и Replica 3.

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

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

Рисунок 16.5 Резервирование с помощью репликации после сбоя источника

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

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

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

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