16.4.1.26 Репликация и остановка источника или реплики
Безопасно останавливать сервер-источник и перезапускать его позже. Когда реплика теряет соединение с источником, она пытается немедленно возобновить соединение и периодически повторяет попытки, если это не удается. По умолчанию попытки повторяются каждые 60 секунд. Это можно изменить с помощью инструкции CHANGE MASTER TO. Реплика также способна обрабатывать перерывы в сетевом соединении. Однако реплика замечает перерыв в сетевом соединении только после того, как не получает данных от источника в течение slave_net_timeout секунд. Если перерывы короткие, можно уменьшить slave_net_timeout. См. Раздел 16.3.2, «Обработка неожиданной остановки реплики».
Некорректная остановка (например, сбой) со стороны источника может привести к тому, что двоичный журнал источника будет иметь конечную позицию меньше последней позиции, прочитанной репликой, из-за того, что файл двоичного журнала источника не был выгружен. Это может привести к тому, что реплика не сможет выполнить репликацию после перезапуска источника. Установка sync_binlog=1 в файле источника my.cnf помогает минимизировать эту проблему, поскольку заставляет источник чаще сбрасывать свой двоичный журнал. Для обеспечения максимальной надежности и согласованности в настройке репликации, использующей InnoDB с транзакциями, также следует установить innodb_flush_log_at_trx_commit=1. С этим параметром содержимое буфера повторения InnoDB записывается в файл журнала при каждой фиксации транзакции и файл журнала сбрасывается на диск. Обратите внимание, что надежность транзакций при этом параметре все равно не гарантируется, поскольку операционная система или аппаратное обеспечение диска могут сообщить mysqld, что операция записи на диск выполнена, даже если это не так.
Безопасна чистая остановка реплики, так как она отслеживает, где она остановилась. Однако будьте внимательны, чтобы у реплики не были открыты временные таблицы; см. Раздел 16.4.1.29, «Репликация и временные таблицы». Некорректные остановки могут привести к проблемам, особенно если кэш диска не был выгружен на диск до возникновения проблемы:
Для транзакций реплика фиксирует и затем обновляет
relay-log.info. Если неожиданно произошел выход из системы между этими двумя операциями, обработка журнала репликации продолжится дальше, чем указано в файле информации, и реплика повторно выполнит события последней транзакции в журнале репликации после перезапуска.Аналогичная проблема может возникнуть, если реплика обновит
relay-log.info, но серверный хост упадет до того, как запись будет выгружена на диск. Чтобы минимизировать вероятность этого, установитеsync_relay_log_info=1в файле репликиmy.cnf. Установкаsync_relay_log_infoв значение 0 не заставляет выполнять принудительные записи на диск, и сервер полагается на операционную систему для периодической выгрузки файла.
Устойчивость вашей системы к подобным проблемам значительно повышается при наличии хорошего источника бесперебойного питания.
© 2025 Oracle
Licensed under the GPLv2 License.