MySQL InnoDB Cluster: автоматичний failover з Shell і Router

MySQL InnoDB Cluster: де ламається автоматичний failover

MySQL InnoDB Cluster тримає запис на одному вузлі-майстрі, решта отримують зміни потоком реплікації. Поки всі вузли в строю, схема працює непомітно: відмову репліки застосунок взагалі не помічає, а відмова майстра має закриватися перемиканням за секунди. Діра відкривається там, де перемикання не запускається — і запис зупиняється повністю.

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

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

Далі вмикається ручний регламент: черговий має помітити, що майстер мовчить, перевірити стан групи, підняти пріоритет потрібного вузла й повернути запис.

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

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

Що дає автоматичне перемикання: вимірюваний ефект

Автоматичне перемикання впроваджують не заради «база сама підніметься», а заради передбачуваного часу простою й зрозумілого списку інцидентів, які черговий взагалі не побачить. Нижче — чотири ефекти, які видно в моніторингу вже через тиждень роботи кластера InnoDB.

Час відновлення після відмови: хвилини ручної роботи проти секунд

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

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

Частка автоматичних перемикань

Приблизно 90-95% відмов одиночного вузла й ведучого закриваються самі: кластер залишається в робочому режимі, а команда дізнається про подію з повідомлення.

Залишається вузька група випадків — втрата кворуму й мережеві розділення, де автоматика зобов’язана зупинити запис, — і рішення там ухвалює інженер, а не таймер.

Передбачуваність відмов і кворум вузлів

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

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

Вікно планових робіт

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

Схеми відмовостійкості MySQL: один майданчик, два ЦОД, хмара

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

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

Тому варіанти розміщення порівнюємо за трьома питаннями: скільки одночасних відмов схема переживає, скільки займає автоматичне перемикання і наскільки синхронний режим здорожчує запис. Нижче — реальні альтернативи, між якими обирають під час проєктування MySQL InnoDB Cluster.

На одному майданчику розумна межа — відмова вузла або обслуговування. Два майданчики закривають аварію ЦОДу, але потребують каналу з малою затримкою й третьої точки для кворуму.

Хмарне розкладання по зонах знімає питання свого заліза, зате додає залежність від міжзонального трафіку.

Порядок впровадження: від аудиту топології до передачі в експлуатацію

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

1. Аудит топології. Знімаємо карту серверів, версії, стан реплікації, обсяги й профіль навантаження. Фіксуємо поточні точки відмови й з’ясовуємо, які вузли взагалі здатні прийняти роль первинного без втрати даних.
2. Проєктування схеми кластера. Визначаємо число вузлів і кворум, розміщення по зонах доступності, режим узгодження запису й поведінку при втраті зв’язку між майданчиками. Тут же вирішуємо, де розміщувати Router і як розподіляти читальне навантаження.
3. Підготовка й перенесення даних. Переводимо дані в узгоджений формат, відновлюємо на нових вузлах, звіряємо контрольні суми по таблицях. Розходження усуваються до включення кластера, а не після.
4. Налаштування перемикання. Задаємо пороги відмови, пріоритети вузлів, тайм-аути й політику повернення попереднього первинного вузла. Окремо описуємо, що відбувається із застосунком у момент зміни лідера.
5. Перевірка сценаріїв відмови. По черзі виводимо з ладу первинний вузол, репліку, Router і цілу зону — заміряємо час відновлення запису й повноту даних після повернення в стрій. Сценарій повторюється, доки результат не стане передбачуваним.
6. Передача в експлуатацію. Віддаємо схеми, політики, регламент резервного копіювання й відновлення, чек-лист чергового. Навчаємо зміну: як читати стан кластера, що робити при втраті кворуму і коли ескалувати.

Конфігурації, схеми й регламенти: комплект при передачі

Кластер залишається працездатним тільки тоді, коли його обслуговує команда, яка розуміє логіку вибору первинного вузла.

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

• Конфігурація кластера — файли налаштувань кожного вузла з поясненнями: параметри реплікації, пороги спрацювання при втраті зв’язку, пріоритет вузлів під час виборів нового первинного й чому вибрано саме ці значення.
• Схема мережі та портів — які порти обслуговують групову реплікацію й MySQL Router, як розведені адреси між вузлами й клієнтами, де вузькі місця та єдині точки відмови.
• Політики доступу й ролі — розподіл привілеїв між адміністратором і сервісним обліковим записом Router, порядок видачі й зміни паролів, що заборонено робити напряму на первинному вузлі.
• Регламент перемикання — покроковий сценарій на випадок відмови первинного вузла: як перевірити статус групи, коли чекати автоматичного вибору нового лідера, а коли перемикання робиться вручну і хто його підтверджує.
• Інструкція з відновлення — повернення вузла після збою, перескладання з резервної копії, перевірка відставання й консистентності перед введенням назад у кластер.
• Регламент чергування — які події та метрики вважати інцидентом, кому ескалувати, що робити в перші хвилини і в якому порядку.
• Карта розміщення — на якому сервері живе який вузол, де Router, які зони відмови переживає схема при втраті одного розміщення.

Кейс: перемикання без втрати транзакцій на трьох вузлах

Ситуація до: ручне відновлення й втрата транзакцій

Кластер із трьох вузлів MySQL тримав замовлення й платежі. При відмові основного вузла запис зупинявся: застосунок повертав помилки, доки черговий інженер підключався до кластера, звіряв позиції реплікації й вручну підвищував одну з реплік.

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

Що змінили

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

Маршрутизацію віддали Router із політикою «тільки первинний вузол», оркестрацію — Shell: підвищення вузла, вихід із розділення мережі й примусове перемикання при втраті кворуму йдуть за регламентом, а не за пам’яттю чергового.

Метрики до і після

• Автоматичне перемикання: 20–40 секунд замість 30–60 хвилин ручного відновлення.
• Втрата підтверджених транзакцій: нуль замість частини незавершених операцій при кожному збої.
• Розділення мережі: меншість вузлів перестає приймати запис, подвійний первинний вузол виключено.
• Навчання: планове відключення вузла, черговий бачить результат перемикання, а не шукає його в логах.

Відмовостійкість зросла без розширення парку серверів: ті самі три вузли тепер переживають втрату одного з них без зупинки запису.

Що робити, якщо база вже розгорнута, а перемикання роблять вручну?

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

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

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

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

Новий лідер вибирається автоматично за більшістю голосів, а Router за лічені секунди перенаправляє трафік на нього.

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

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

Часті технічні сумніви: відповідаємо по суті

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

Як кластер поводиться при втраті зв’язку між майданчиками?

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

Чи потрібно переробляти застосунок?

Так, але точково. Підключення йде через MySQL InnoDB Cluster у зв’язці з Router — застосунок не знає адрес конкретних вузлів і має коректно перепідключатися при зміні ведучого.

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

Як поєднати резервне копіювання й планове обслуговування?

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

Планові роботи йдуть через ручне перемикання ролі: вузол виводять із групи, оновлюють і повертають, після чого він сам наздоганяє зміни.

Обговоримо вашу задачу: що уточнити перед стартом

Щоб оцінка була предметною, а план — виконуваним, нам потрібно зрозуміти поточний контур бази й вимоги до відмовостійкості.

Опишіть задачу у вільній формі, а ми повернемося з оцінкою та планом робіт: складом етапів, строками й переліком перевірок, які підтвердять, що автоматичне перемикання справді працює. Для точної оцінки зазвичай достатньо відповідей на кілька питань.

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

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