Чому MariaDB Galera Cluster втрачає синхронність під навантаженням
MariaDB Galera Cluster підтверджує запис не на одному вузлі, а після того, як транзакцію сертифікували всі учасники. Поки вузли встигають однаково, підтвердження запису й реплікація нероздільні: втрат даних у разі відмови одного сервера немає.
Схема ламається саме тоді, коли один вузол перестає встигати — механізм регулювання потоку пригальмовує весь кластер до швидкості найповільнішого учасника.
Другий крок до збою — випадіння вузла. Сервер відвалився через мережу або застряг на повній передачі стану, ті, що залишилися, не набирають більшість, і розпад кворуму переводить частину кластера в режим без права запису.
Застосунок отримує помилку про неготовність вузла, з’єднання висять в очікуванні, і запис зупиняється повністю, хоча диски цілі й дані на місці.
Небезпечніший зворотний сценарій: поки кластер розділений, менша частина встигає прийняти й підтвердити транзакції клієнту, а після відновлення зв’язку вони не проходять сертифікацію й відкидаються.
Так підтверджена транзакція не доїжджає до інших вузлів — це вже не відмовостійкість бази даних, а розходження, яке доводиться звіряти вручну.
На піку такий збій імовірніший: зростають черги сертифікації, довше утримуються блокування запису, а сплеск на одному вузлі через регулювання потоку розганяє затримки на всіх. Будь-який перезапуск або передача стану на гарячому кластері вибиває кворум особливо легко.
Розбираємо, як це закривається: як рахувати кворум і вагу вузлів, чим утримати відсталий вузол у кластері та як побудувати схему, за якої відмова вузла не призводить до блокування запису.
Що дає синхронна реплікація з підтвердженням запису
Запис вважається підтвердженим лише тоді, коли його прийняв кворум вузлів, а не один провідний сервер.
Клієнт отримує відповідь уже після фіксації на більшості — тому клас відмов «втрата підтверджених даних» зникає: якщо вузол випадає одразу після відповіді, транзакція все одно залишається на інших. MariaDB Galera Cluster закриває це на рівні самої реплікації, без доопрацювань у застосунку.
У разі відмови вузла кворум перезбирається сам, а маршрутизація трафіку за секунди переводить клієнтів на живі вузли. Час перемикання вимірюється одиницями секунд і не залежить від обсягу бази — перемикання не чекає застосування журналів. Застосунок бачить короткий розрив з’єднань, а не простій на хвилини.
Вузол, що повернувся, відновлюється гарячим способом: отримує знімок стану й наздоганяє потік змін, поки інші продовжують приймати запис. Запис при цьому не зупиняється — зниження простою досягається завдяки тому, що відновлення відбувається паралельно з робочим навантаженням.
Плата за це — затримка запису визначається найповільнішим вузлом набору, тому мережу між вузлами та їхню кількість добираємо усвідомлено: непарний кворум, без зайвих учасників. Слабка ланка видно за метриками потоку реплікації, і це перше, що ми перевіряємо під час налаштування.
Режими реплікації MariaDB: порівняння варіантів
Режими реплікації різняться не «повнотою», а тим, хто підтверджує фіксацію зміни та що відбувається в разі розходження вузлів. Від цього залежать поведінка при збої, чутливість до затримки між майданчиками та те, який відкат узагалі можливий.
| Варіант | Коли підходить | Обмеження режиму |
|---|---|---|
| Асинхронна реплікація | звітні копії, рознесені майданчики, де втрата останніх змін допустима | основний вузол підтверджує фіксацію, не дочекавшись копії: у разі збою до передачі журналу різниця губиться безповоротно |
| Напівсинхронна реплікація | потрібен баланс між швидкістю запису й гарантією, що копія прийняла журнал | підтвердження надходить до застосування на копії, тому під час перемикання частина змін ще наздоганяє; поведінка в разі недоступності копії задається політикою таймауту |
| Синхронне підтвердження (Galera) | критичні дані, де розходження вузлів неприпустиме, а вузли стоять в одній мережі з малою затримкою | фіксація проходить лише на більшості вузлів: втрата кворуму зупиняє запис, а зростання кількості вузлів збільшує час відгуку на запис |
| Копія із затримкою застосування | захист від помилкової масової зміни | перемикання не прискорює, потребує окремого вузла та запасу місця під журнали |
Вибір не бінарний: в одній інсталяції синхронний кластер зазвичай несе критичні бази, а асинхронна копія — звітність і аналітику. Так навантаження читання йде з основного контуру, а вимоги до затримки між майданчиками залишаються виконуваними.
Впровадження відмовостійкого кластера: етапи робіт
Кластер синхронної реплікації на MariaDB Galera не збирають «на живу»: порядок робіт визначає, буде перемикання в разі відмови передбачуваним чи перетвориться на ручні операції під тиском. Кожен етап завершуємо артефактом, який перевіряємо до переходу на наступний.
- Аудит поточної схеми. Топологія, розмір гарячих даних, затримки між вузлами, зміни структури поза регламентом, поведінка застосунку в разі помилки запису. Результат — карта вузьких місць і перелік запитів, неприпустимих у кластері: довгі блокувальні транзакції, масові вставки без розбиття.
- Проєктування топології. Кількість вузлів, кворум, окремий арбітр поза основною зоною відмови, режим підтвердження транзакції записом на кворум. Тут же фіксуємо поведінку в разі втрати кворуму: зупинка запису автоматично або за рішенням чергового.
- Налаштування синхронного запису. Параметри потоку реплікації, обмеження розміру транзакції для наздоганяння змін, поведінка вузла в разі відставання, переведення вузла в режим без запису. Перевіряємо, як застосунок переживає відкат транзакції та перепідключення до іншого вузла.
- Тести відмови. Плановий вивід вузла, різка зупинка, розрив мережі між зонами, втрата кворуму, повне перезбирання вузла з донора. Фіксуємо час відновлення запису та кількість втрачених підтверджених транзакцій — ціль нуль.
- Резервне копіювання та відновлення. Знімок з вузла-донора, перевірка відновлення на окремому контурі, регламент повної синхронізації, коли наздоганяння змін неможливе.
- Передача в експлуатацію. Моніторинг стану вузлів і відставання, інструкції черговому, порядок заміни вузла й оновлення структури у вікно. Далі — супровід, поки команда не проведе заміну вузла самостійно.
Конфігурації, схеми кворуму та регламенти перемикання
Після впровадження в команди замовника залишається не лише працюючий кластер, а й комплект артефактів, за якими його можна експлуатувати без нас. Нижче — те, що ми передаємо в сховище конфігурацій замовника й розбираємо на передачі.
- Файли конфігурації вузлів. Повний набір параметрів синхронної реплікації: ім’я кластера, режим підтвердження запису, поведінка вузла в разі втрати зв’язку з групою, ліміти на потік змін. Розкладені по машинах і продубльовані в системі контролю версій.
- Схема розміщення вузлів. Скільки вузлів, у яких зонах доступності, як розподілений кворум, які затримки між майданчиками закладали й чому саме такий склад голосуючих.
- Регламент перемикання. Покроковий порядок керованого виводу вузла, дії в разі втрати кворуму, точка, у якій ухвалюється рішення про переведення трафіку на резервний майданчик.
- Правила доступів. Ролі для застосунку, службової діагностики та відновлення, звідки дозволені підключення, хто має право змінювати параметри кластера й як це фіксується.
- Документація з відновлення. Сценарії холодного старту групи, підйом одного відсталого вузла, порядок роботи з резервною копією та звірка стану після повернення.
- Чек-листи. Перевірки перед зміною конфігурації, після аварійного перемикання та регулярний контроль розходження даних між вузлами.
- Карта метрик і оповіщень. Які показники вузла й кластера вважаються нормою, які потребують втручання чергового, кому надходить сигнал.
Кейс: кластер інтернет-магазину без простою в разі відмови вузла
Як було до
Магазин працював на одній основній базі та асинхронній репліці. Коли вузол ішов, репліка відставала, і частина замовлень, оформлених у момент збою, зникала — частка втрачених транзакцій сягала 0.3% добового потоку.
Про розходження дізнавалися зі скарг покупців, тобто вже після того, як клієнт не отримав підтвердження замовлення.
Перемикання робили руками: черговий інженер піднімав репліку, змінював точку підключення в конфігурації застосунку й лише потім знімав режим обслуговування. Простій становив від 4 до 11 хвилин, а кожна четверта відмова закінчувалася ручним перезбиранням вузла з резервної копії.
Що змінили й що стало
Зібрали кластер із трьох вузлів із синхронною реплікацією: запис підтверджується лише після того, як його прийняла більшість вузлів, тому втрата замовлень у разі відмови одного вузла перестала бути можливою.
Відмову відпрацьовує автоматика — два вузли, що залишилися, зберігають кворум, і кластер продовжує приймати записи без участі чергового.
Час перемикання скоротився з хвилин до 3-8 секунд, частка втрачених транзакцій — з 0.3% до нуля, частка ручних відновлень — з чверті відмов до одного з десяти, і лише коли диск вузла недоступний зовсім.
Розбір інциденту займає близько 20 хвилин: у журналі видно, який вузол випав, чому й коли повернувся в стрій, — раніше на звірку логів ішли години.
Налаштування ми звіряли з двома незалежними джерелами — документація Galera Cluster і звіти спільноти щодо кворуму: вони підтверджують, що вибраний режим дає передбачувану відмову, а не тиху втрату даних.
Що робити, якщо вже розгорнуто асинхронний кластер?
Перехід можливий без тривалого вікна недоступності: дані на репліках уже є, змінюється лише спосіб їх приймання та підтвердження запису. Порядок тут зворотний звичному — спочатку вводимо в синхронний кластер одну репліку, а поточний майстер продовжує працювати як раніше.
Перед цим перевіряємо поточну конфігурацію. Усі таблиці мають бути InnoDB і з первинним ключем: без ключа синхронне застосування рядків працює неефективно.
Дивимося, чи не зростає лаг репліки, чи збігаються схеми на вузлах, чи немає прямих підключень до реплік на читання — після перемикання це вже рівноправні учасники кластера.
Окремо — довгі транзакції та зміна структури таблиць: вони узгоджуються між вузлами й на великій таблиці можуть загальмувати запис.
Зворотна сумісність застосунків — головний ризик. Асинхронна схема терпить конфлікти: розходження накопичуються й спливають пізніше. Синхронна повертає їх одразу помилкою транзакції, тому код має вміти повторити операцію, а не впасти.
Друге — точка підключення: прописаний за іменем майстер змінюють на адресу кластера, інакше розподіл запису не запрацює.
План міграції: фіксуємо налаштування, піднімаємо новий вузол поруч із реплікою та переносимо дані фізичною копією — перелив дампом створює те саме довге вікно. Потім переводимо застосунок, додаємо інші вузли й стежимо за кворумом.
Саме вікно недоступності — хвилини на зміну точки підключення та перевірку запису з читанням. Відкат простий: повернути застосунок на попередній майстер, він залишається холодним резервом, поки кластер не відпрацює під навантаженням.
Часті технічні питання перед впровадженням кластера
На етапі проєктування важливо перевірити не саму реплікацію, а поведінку кластера в нештатних сценаріях: обрив зв’язку між майданчиками, додавання вузла під навантаженням, відгук запису. Нижче — п’ять питань інженерного рівня з короткими відповідями.
Скільки вузлів потрібно для кворуму?
Три — мінімальний склад, за якого кластер переживає відмову одного вузла й зберігає кворум. Два вузли відмовостійкі, але без запасу: втрата одного залишає один голос, і кластер переходить у режим лише для читання. Для двох майданчиків додаємо легкий арбітр без копії даних.
Що відбувається при розділенні мережі?
Менша частина втрачає кворум і переходить у режим лише для читання — запис на ній зупиняється, щоб версії даних не розійшлися. Більша частина продовжує обслуговувати транзакції, а після відновлення зв’язку відсталі вузли наздоганяють стан самі.
Чи можна додати вузол на ходу?
Так, зупинка сервісу не потрібна. Новий вузол отримує копію даних і включається в голосування лише після наздоганяння. На час повної передачі копії донором виступає один вузол — його навантаження заздалегідь розподіляємо, щоб не просадити відгук.
Чи сповільнює синхронна реплікація запис?
Відгук запису визначає затримка мережі між вузлами, а не диск. У межах майданчика це частки мілісекунд, між регіонами — помітніше. Групова фіксація об’єднує паралельні транзакції в один раунд узгодження, тому пропускна здатність при масовому навантаженні не просідає.
Як вузол відновлюється після збою?
Після короткої відсутності він наздоганяє зміни з журналу й повертається в стрій без повної копії бази. Якщо відстав сильніше, ніж зберігається журнал, запускається повна передача. Розходження даних між вузлами ловиться окремо й потребує перезбирання вузла.
Обговоримо задачу та повернемося з оцінкою й планом
Щоб оцінка була по суті, а не «на око», для старту потрібні вихідні дані з інфраструктури та вимоги до доступності.
Опишіть поточну схему реплікації, кількість вузлів і майданчиків, обсяги баз і профіль навантаження на запис — цього достатньо, щоб зрозуміти, які режими кворуму й синхронізації підійдуть саме вам.
- Схему поточної топології: скільки вузлів, як рознесені по майданчиках, де зараз точки відмови.
- Обсяги та характер навантаження: розмір баз, співвідношення читання й запису, пікові періоди.
- Вимоги до доступності: допустимий час простою під час перемикання та чи потрібен автоматичний перехід у разі відмови вузла.
- Вимоги до узгодженості: які транзакції зобов’язані підтверджуватися на більшості вузлів, а де достатньо асинхронної реплікації.
- Як влаштовані резервне копіювання та відновлення — щоб план робіт не зламав чинні процедури.
- Обмеження щодо вікна робіт: коли конфігурацію можна змінювати без впливу на користувачів.
Натомість повернемося з планом робіт із впровадження: поетапне переведення вузлів, склад кластера, порядок перевірок і порядок приймання з вимірюваними критеріями. Заздалегідь фіксуємо, яку відмову кластер зобов’язаний переживати й за який час повертається в норму після збою. Опишіть задачу — обговоримо деталі та повернемося з оцінкою й планом.
