Репликация MySQL после обрыва VPN: сначала прочитайте оба этапа

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

Два этапа, два отдельных ответа

Обычная асинхронная реплика выполняет две работы. Получатель подключается к источнику, вытягивает события и записывает их локально в журнал передачи. Применитель читает этот журнал и выполняет события на реплике. Когда путь обрывается, получатель останавливается немедленно, а применитель продолжает обрабатывать накопившийся объём, который уже есть на диске. Поэтому один сбой порождает два разных вопроса: вернулось ли соединение и применена ли накопленная работа? Если считать их одним вопросом, два состояния усредняются в вводящий в заблуждение ответ.

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

Читайте канал правильной командой

В MySQL 8.4 SHOW REPLICA STATUS возвращает одну строку на каждый настроенный канал, поэтому читайте строку нужного вам канала, а не первую в списке. Replica_IO_Running отличает подключённый получатель от подключающегося или остановленного, а Replica_SQL_Running описывает применитель. Читайте рядом столбцы ошибок, потому что получатель, который переподключается и сразу сбоит, оставляет сообщение, которого не покажет ни один флаг состояния. Старые выпуски используют другие имена столбцов, поэтому не переводите старый рецепт, просто переименовав команды.

Проверьте также идентичность источника и все настроенные фильтры. Реплика, направленная на неверный источник или отфильтрованная уже, чем вы думаете, сообщает о здоровье, реплицируя не то, что вы ожидаете.

Почему нулевое отставание может лгать

Значение отставания сравнивает отметку времени последнего применённого события с текущим временем. Когда получатель был остановлен на час, применитель может обработать накопленное и дойти до конца полученного, и тогда число падает до нуля, хотя реплика отстаёт от источника на час. Метрика измеряет очередь применителя, а не актуальность реплики.

Вместо этого сравните выполненные транзакции с тем, что доступно на источнике. Такое сравнение переживает остановленный получатель.

Реальное окно восстановления задаёт срок хранения

Чтобы догнать, источник должен ещё хранить транзакции, нужные реплике. После их очистки реплика не может их получить, и никакое переподключение этого не изменит.

При авто-позиционировании GTID сбой очевиден: реплика запрашивает историю, которой у источника уже нет, и отказывается продолжать. Тогда варианты — получить недостающие события с источника, где они ещё есть, или пересобрать из резервной копии и дать ей догнать. Пропуск разрыва — это не догоняние, и он оставляет реплику, данные которой тихо неполны. Планируйте окно, сравнивая ожидаемую длительность сбоя со сроком хранения бинарного журнала на источнике и темпом изменений, потому что эти три числа решают, восстановим ли сбой вообще.

Проверяйте догоняние, а не цвет индикатора

Восстановите путь, включая разрешение имён и безопасность транспорта, затем наблюдайте, переподключится ли существующий канал по собственной политике. Дайте ему определённый интервал до вмешательства и зафиксируйте прогресс приёма и применения на обоих концах этого интервала. Канал, который перезапускается, и канал, который актуален, — разные находки.

Подтвердите, что применитель достиг текущей позиции источника, а не только конца старого накопления. Проверьте, что в применителе не ждёт ошибка, потому что одно неудачное событие останавливает прогресс, пока получатель продолжает сообщать о соединении. Затем зафиксируйте доказательства: имя канала, состояния обоих этапов, выполненную позицию и время. Зелёный индикатор — это утверждение; позиция — факт.