Нет в настоящий момент никакого официального решения для того, чтобы обеспечить failover между ведущим устройством и ведомыми устройствами в случае отказа. С в настоящий момент доступными функциями необходимо бы установить ведущее устройство и ведомое устройство (или несколько ведомых устройств), и записать сценарий, который контролирует ведущее устройство, чтобы проверить, произошло ли это. Затем дайте команду своим приложениям и ведомым устройствам изменять ведущее устройство в случае отказа.

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

Выполните свои ведомые устройства с --log-bin опция и без --log-slave-updates. Таким образом ведомое устройство готово стать ведущим устройством, как только Вы выходите STOP SLAVE; RESET MASTER, и CHANGE MASTER TO оператор на других ведомых устройствах. Например, предположите, что Вам показали структуру в рисунке 16.4, "Избыточность Используя Репликацию, Начальная Структура".

В этой схеме, MySQL Master содержит основную базу данных, MySQL Slave узлы являются ведомыми устройствами репликации, и Web Client машины выпускают чтения базы данных и записи. Веб-клиенты, которые выпускают только чтения (и обычно соединялся бы с ведомыми устройствами) не показывают, поскольку они не должны переключиться на новый сервер в случае отказа. Для более подробного примера структуры репликации масштаба чтения-записи см. Раздел 16.3.3, "Используя Репликацию для Масштаба".

Каждый MySQL Slave (Slave 1, Slave 2, и Slave 3) ведомое устройство, работающее с --log-bin и без --log-slave-updates. Поскольку обновления, полученные ведомым устройством от ведущего устройства, не зарегистрированы двоичный журнал если --log-slave-updates определяется, двоичный файл входят в систему, каждое ведомое устройство пусто первоначально. Если по некоторым причинам MySQL Master становится недоступным, можно выбрать одно из ведомых устройств, чтобы стать новым ведущим устройством. Например, если Вы выбираете Slave 1, все Web Clients должен быть перенаправлен к Slave 1, который зарегистрирует обновления к его двоичному журналу. Slave 2 и Slave 3 должен тогда тиражироваться от Slave 1.

Причина выполнения ведомого устройства без --log-slave-updates должен препятствовать тому, чтобы ведомые устройства получили обновления дважды в случае, если Вы заставляете одно из ведомых устройств становиться новым ведущим устройством. Предположите это Slave 1 имеет --log-slave-updates включенный. Затем это запишет обновления, из которых это получает Master к его собственному двоичному журналу. Когда Slave 2 изменения от Master к Slave 1 как его ведущее устройство, это может получить обновления из Slave 1 то, что это уже получило из Master

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

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

Как только новая репликация на месте, Вы должны будете тогда сообщить каждому Web Client направить его операторы к Slave 1. От той точки на, все операторы обновлений, отправленные Web Client к Slave 1 пишутся двоичному журналу Slave 1, который тогда содержит каждый оператор обновления, отправленный Slave 1 с тех пор Master умерший.

Получающуюся структуру сервера показывают в рисунке 16.5, "Избыточность Используя Репликацию, После Основного Отказа".

Когда Master произошел снова, следует выпустить на этом то же самое CHANGE MASTER TO как выпущенное на Slave 2 и Slave 3, так, чтобы Master становится ведомым устройством S1 и подбирает каждого Web Client записи, которые это пропустило, в то время как это снижалось.

Сделать Master ведущее устройство снова (например, потому что это - самая мощная машина), использует предыдущую процедуру как будто Slave 1 было недоступно и Master должно было быть новое ведущее устройство. Во время этой процедуры не забывайте работать RESET MASTER на Master перед созданием Slave 1, Slave 2, и Slave 3 ведомые устройства Master. Иначе, они могут поднять старый Web Client записи те, до точки, в который Master стал недоступным.

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

Хороший способ держать Ваши приложения в курсе относительно расположения ведущего устройства при наличии динамической записи DNS для ведущего устройства. С bind можно использовать nsupdate динамически обновить Ваш DNS.