Реплікація MySQL після обриву VPN: спершу прочитайте обидва етапи

Моніторинг реплікації стає червоним, коли падає VPN, і перший імпульс — скинути позицію. Саме цей імпульс перетворює мережевий збій на проблему з даними. Обірваний шлях нічого не говорить про те, що репліка отримала або застосувала, а це два етапи з двома станами. Прочитайте їх окремо, перш ніж щось змінювати.

Два етапи, дві окремі відповіді

Звичайна асинхронна репліка виконує дві роботи. Отримувач підключається до джерела, витягує події та записує їх локально в журнал передавання. Застосовувач читає цей журнал і виконує події на репліці. Коли шлях обривається, отримувач зупиняється негайно, а застосовувач продовжує обробляти накопичене, яке вже є на диску. Тож один збій породжує два різні питання: чи повернулося з'єднання і чи застосовано накопичену роботу? Якщо вважати їх одним питанням, два стани усереднюються в оманливу відповідь.

Відновлення отримувача говорить, що шлях працює. Воно нічого не говорить про те, наскільки застосовувач відстав, і чи натрапив він на помилку, поки був від'єднаний.

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

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

Перевірте також ідентичність джерела та всі налаштовані фільтри. Репліка, скерована на хибне джерело або відфільтрована вужче, ніж ви думаєте, повідомляє про здоров'я, реплікуючи не те, що ви очікуєте.

Чому нульове відставання може брехати

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

Натомість порівняйте виконані транзакції з тим, що джерело має в наявності. Таке порівняння переживає зупинений отримувач.

Реальне вікно відновлення визначає збереження

Щоб наздогнати, джерело має ще зберігати транзакції, потрібні репліці. Після їх очищення репліка не може їх отримати, і жодне перепідключення цього не змінить.

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

Перевіряйте наздоганяння, а не колір індикатора

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

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