16.4.1.19. Репликация и Основные или Ведомые Завершения работы

Безопасно завершить работу главного сервера и перезапустить это позже. Когда ведомое устройство теряет свое соединение с ведущим устройством, ведомое устройство пытается повторно соединиться сразу и повторения периодически, если это перестало работать. Каждые 60 секунд значение по умолчанию должно повторить. Это может быть изменено с CHANGE MASTER TO оператор. Ведомое устройство также в состоянии иметь дело с сетевыми отключениями электричества связи. Однако, ведомое устройство замечает сетевое отключение электричества только после получения никаких данных от ведущего устройства для slave_net_timeout секунды. Если Ваши отключения электричества коротки, можно хотеть уменьшиться slave_net_timeout. См. Раздел 5.1.4, "Системные Переменные Сервера".

Небезопасное завершение работы (например, катастрофический отказ) на основной стороне может привести к основному двоичному журналу, имеющему заключительную позицию меньше чем новая позиция, считанная ведомым устройством, из-за основного двоичного файла журнала, не сбрасываемого. Это может заставить ведомое устройство не быть в состоянии тиражироваться, когда ведущее устройство возвращается. Установка sync_binlog=1 в ведущем устройстве my.cnf файл помогает минимизировать эту проблему, потому что это заставляет ведущее устройство сбрасывать ее двоичный журнал более часто.

Завершение работы ведомого устройства чисто безопасно, потому что оно отслеживает то, где оно кончило. Однако, будьте осторожны, что у ведомого устройства нет временных таблиц открытыми; см. Раздел 16.4.1.22, "Репликация и Временные таблицы". Небезопасные завершения работы могли бы произвести проблемы, особенно если бы дисковый кэш не был сброшен к диску прежде, чем проблема произошла:

Для транзакций, ведомых фиксаций и затем обновляет relay-log.info. Если катастрофический отказ происходит между этими двумя операциями, релейная обработка журнала продолжится далее, чем информационный файл указывает, и ведомое устройство повторно выполнит события от последней транзакции в релейном журнале после того, как это было перезапущено.
Подобная проблема может произойти, если ведомое устройство обновляет relay-log.info но катастрофические отказы узла сервера перед записью были сброшены к диску. Чтобы минимизировать шанс этого появления, установить sync_relay_log_info=1 в ведомом устройстве my.cnf файл. Значение по умолчанию sync_relay_log_info 0, который не заставляет записи быть вызванными к диску; сервер полагается на операционную систему, чтобы время от времени сбрасывать файл.

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