MariaDB vs Percona Server: повноцінна заміна чи пастка сумісності?

Що насправді означає «повноцінна заміна» (і чому це кусaється)

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

MariaDB і Percona Server обидва носять бейдж «сумісний з MySQL», але сумісні вони в різних напрямах і на різних шарах:

• Протокольна сумісність: клієнти зазвичай можуть підключатися. «Зазвичай» ховає нюанси плагінів автентифікації та TLS.
• Сумісність SQL‑діалекту: базовий SQL працює, але крайні випадки (JSON, оконні функції в старих версіях, підказки оптимізатора) можуть різнитися.
• Поведінкова сумісність: одна й та сама схема й запит можуть повертати ті самі рядки… з різною продуктивністю та блокуванням.
• Операційна сумісність: інструменти бекапу, семантика реплікації і системні таблиці важать більше, ніж багато команд визнають.

Якщо ви міняєтеся між MariaDB і Percona Server, пастка — в думці, що обидва «просто MySQL». Percona Server зазвичай тісно слідує за upstream MySQL (бо по суті це MySQL з доповненнями). MariaDB давно пішла власною форк‑дорогою і продовжує розвиватися під маркою «MySQL», змінюючи внутрішню будову й функції.

Жарт №1: «Повноцінна заміна» — це як «гаряча заміна» в запиті на зміну: означає, що ви будете міняти її, поки вона гаряча.

Ось позиція, що рятує команди: розглядайте переміщення MariaDB ↔ Percona Server як великий міграційний рух рушія, а не як дрібний патч. Плануйте його серйозно. Це не PostgreSQL ↔ MySQL, але ближче, ніж хочеться вірити.

Походження та історичний контекст (факти, які забувають)

Коротка історія, бо вона пояснює сучасні мінні поля сумісності. Це не тривіальні подробиці; вони передбачають, як поведінка оновлення/міграції проявиться на практиці.

1. MariaDB відокремилася від MySQL у 2009 році через занепокоєння щодо поглинання Oracle Sun і подальшого керування MySQL.
2. Percona Server починався як дистрибутив, орієнтований на продуктивність, який тримається близько до upstream MySQL, додаючи інструментацію й корпоративні можливості.
3. MariaDB цілеспрямовано розійшлася: зберігаючи сумісність клієнтського протоколу MySQL, вона ввела власні функції й механізми зберігання (зокрема Aria) та власну роботу з оптимізатором.
4. GTID — це не «один GTID»: реалізація GTID у MariaDB відрізняється від MySQL/Percona GTID, що впливає на інструменти відновлення після відмови й змішані топології.
5. Mariabackup походить із лінії XtraBackup, але поведінка, зв’язування з версіями та крайні випадки відрізняються настільки, що «використовуйте будь‑який» — ризиковано.
6. Системні таблиці та словник даних еволюціонували по‑різному: MySQL 8 ввів великі зміни словника; MariaDB обрала інший шлях. Інструменти, що читають mysql.* таблиці, можуть ламаються.
7. JSON — постійна проблема: MariaDB історично зберігала JSON як рядок із функціями; MySQL трактує його як нативний тип із відмінною семантикою індексування.
8. Плагіни автентифікації розійшлися: MySQL/Percona перейшли через caching_sha2_password; MariaDB опиралася іншим наборам плагінів і різним налаштуванням за замовчуванням залежно від версії.
9. Шляхи оптимізатора не взаємозамінні: обидва мають моделі витрат і евристики, що змінюють плани запитів у «дозволений» спосіб, але можуть стати операційно вибухонебезпечними.

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

Одна цитата, яку варто докласти до кожного плану міграції: «Надія — це не стратегія.» — Джеймс Кемерон.

Карта сумісності: де MariaDB і Percona Server розходяться

1) Версіювання та орієнтація на функції

Percona Server зазвичай відслідковує випуски upstream MySQL (і їхню семантику), тому його ціль сумісності — «поведінка MySQL + доповнення». MariaDB орієнтується на «поведінку MariaDB», залишаючись MySQL‑подібною для загальних кейсів.

Якщо ваш постачальник ПО каже «сумісно з MySQL 8», це зазвичай природніше лягатиме на Percona Server для MySQL 8, ніж на MariaDB. Якщо постачальник каже «підтримує MariaDB», не тлумачте це як «підтримує MySQL». Це два різні обіцянки.

2) Системні таблиці, метадані та припущення інструментів

Багато корпоративних скриптів чинять злочини проти бази mysql. Вони безпосередньо питають за застарілими системними таблицями. Або парсять вивід SHOW PROCESSLIST як стабільне API. Або припускають, що колонки information_schema однакові скрізь.

Це працює — поки не перестає. Під час міграцій найчастіше першим падає саме інструментарій, а не сама база.

3) Плагіни і функції, що звучать схоже, але різні

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

4) InnoDB: «те ж ім’я движка», але інші патчі

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

Практичний висновок: не припускайте, що ваш файл налаштувань InnoDB переносний дослівно. Збережіть дух налаштувань, а не буквальні значення.

Реплікація та HA: GTID, відмови і гострі кути

GTID: великий розвилка сумісності

Якщо ви візьмете з цієї статті одне — візьміть це: GTID у MariaDB і GTID у MySQL/Percona — це різні системи. Вони вирішують схожі проблеми, але з різними форматами і операційною поведінкою.

Це важливо для:

• Автоматизації відновлення після відмов: інструменти, що припускають семантику MySQL GTID, можуть небезпечно просувати вузли на MariaDB і навпаки.
• Змішаних кластерів: «Ми тимчасово зробимо репліки MariaDB від Percona primary» — це не просте рішення. Зазвичай це короткостроковий міст із суворими обмеженнями, а не архітектура для постійної роботи.
• Відновлення до точки в часі: ваші робочі процеси відновлення на основі binlog можуть потребувати коригування, особливо щодо строгості і консистентності GTID.

Фільтри реплікації і поведінка row-based

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

Group replication і очікування Galera

Percona Server часто розгортається в топологіях типу MySQL‑реплікації або Percona XtraDB Cluster (на базі Galera). MariaDB теж має варіанти з Galera. Схожість закінчується, коли ви усвідомлюєте, що кожна екосистема має свої значення за замовчуванням, інструментарій і обробку крайніх випадків.

Якщо ваша HA‑історія залежить від «Galera все вирішить», ви передаєте правильність системі, яка все ще потребує від вас визначення політик конфліктів, шаблонів запису й рішень кворуму.

Бекап і відновлення: XtraBackup vs mariabackup і реальність відновлення

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

XtraBackup (Percona) vs mariabackup (MariaDB)

Операційно обидва інструменти прагнуть виконати гарячі фізичні бекапи InnoDB. На практиці:

• Зв’язка з версіями: інструменти бекапу вимогливі до версій сервера. «Достатньо близько» стає «не зможе підготувати бекап».
• Різниця в шифруванні/стисненні: опції і значення за замовчуванням відрізняються; пайплайни відновлення ламаються, якщо ви припускаєте, що прапори портативні.
• Інкрементальні бекапи: працюють, поки не перестануть — особливо після апгрейдів або зміни налаштувань redo log.

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

Жарт №2: Бекапи — як парашути: якщо ви тестували їх лише раз, це зазвичай останній раз, коли вони знадобляться.

Безпека та автентифікація: плагіни, TLS і несподіванки клієнтів

Плагіни автентифікації можуть зробити «сумісні» клієнти нездатними підключитися

Бібліотеки клієнтів часто закладають припущення про плагіни автентифікації за замовчуванням. Коли MySQL змінив значення за замовчуванням (зокрема щодо caching_sha2_password у MySQL 8), це спричинило багаторічну хвилю проблем підключення в різних мовах і пакетах ОС.

MariaDB зробила інші вибори й запропонувала інші плагіни. Percona слідує за MySQL. Це означає, що той самий образ контейнера додатка може підключатися до одного сервера і падати при підключенні до іншого — без змін у коді.

TLS і невідповідність політик шифрів

TLS «працює», поки ваша команда з комплаєнсу не затвердить нові набори шифрів або мінімальні версії. Різні збірки серверів і пакети дистріб’юторів можуть мати різне зв’язування з OpenSSL, різні значення за замовчуванням і різні прийняті набори шифрів.

Зробіть безпеку явною: визначте версію TLS, очікувані шифри та версії клієнтських бібліотек як частину вашого рукбуку.

Оптимізатор і продуктивність: проблема «той самий запит, інший план»

Найдорогоцінніші інциденти — ті, де нічого не «зламано». Просто повільніше. Достатньо повільно, щоб розгорнулись каскадні проблеми.

Чому плани змінюються

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

• Різні моделі витрат та обробка статистики
• Різні значення за замовчуванням для тимчасових таблиць, лімітів пам’яті та буферів сортування
• Різні інтерпретації підказок або різна доступна синтаксична підказка
• Різна поведінка колацій, що впливає на використання індексу

Практичні поради

Перед міграцією зафіксуйте репрезентативні плани запитів і фактичну поведінку в runtime. Не лише EXPLAIN — також розподіл латентностей, rows examined і контенцію. Після міграції порівняйте знову на тій самій формі даних.

Якщо ви цього не робитимете, чесно скажіть: ви граєте в азартну гру, а не інженерите.

Обсервабіліті та інструменти: чого ваші дашборди не скажуть

Більшість налаштувань «моніторингу MySQL» — це купа припущень: які статусні змінні існують, які таблиці performance_schema увімкнені, як виглядають slow log і який користувач має права читати все.

Екосистема Percona часто спирається на конвенції Percona Toolkit і розширені метрики. Середовища MariaDB можуть мати інші значення за замовчуванням інструментації й різну зрілість performance_schema залежно від версії. Обидві сторони можна зробити спостережуваними, але не шляхом припущення, що ваш експортер конфіг переноситься.

А ще: перевірте адміністративні скрипти. Все, що парсить SHOW ENGINE INNODB STATUS і грепає англійські рядки — ризик. Працюватиме допоки не перестане, а потім розбудить вас о 03:12 із нісенітницею.

Швидкий план діагностики

Це сценарій «ми щойно мігрували й тепер повільно/нестабільно». Мета — знайти вузьке місце за хвилини, а не виграти суперечку про те, чия база краща.

Перше: визначте, чи ліміт — CPU, IO, блокування чи реплікація

• CPU: високий user CPU, багато runnable потоків, плани запитів змінилися, відсутні індекси або нова поведінка сортування/тимчасових таблиць.
• IO: високі await, пропуски буферу, тиск на redo/flush, повільне сховище, невірний innodb_flush_method.
• Блокування: спайки очікувань на блокування, дедлоки, довгі транзакції, різні значення isolation по замовчуванню.
• Реплікація: відставання реплік, вузькі місця застосування relay log, невідповідність GTID, зміни формату рядків.

Друге: перевірте топ‑3 запити й їхні плани

Не гортайте тисячі метрик. Визначте найбільших порушників (за загальним часом та p95). Порівняйте плани з базовими.

Третє: підтвердіть базові операційні речі

• Чи налаштовано бінлоги як очікується?
• Чи сервер у правильному SQL‑mode?
• Чи зміни автентифікації не спричинили шквал пеерконектів?
• Чи шлях бекапу/відновлення не змінив макет даних (наприклад, різні опції file‑per‑table)?

Четверте: вирішіть, відкат, налаштування чи виправлення запитів

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

Поширені помилки: симптом → корінь → виправлення

1) Додаток не може підключитися після міграції

Симптоми: «Auth plugin not supported», збої рукостискання або помилки TLS з клієнтів.

Корінь: значення плагіна автентифікації відрізняється; бібліотека клієнта застаріла; невідповідність політики TLS.

Виправлення: уніфікуйте плагін автентифікації під підтримуваний клієнтами; оновіть бібліотеки клієнтів; явно налаштуйте TLS і перевірте від відомого робочого клієнта.

2) Запити правильні, але повільні в 5–50×

Симптоми: стрибки p95, зріст CPU, slow log повний раніше нормальних запитів.

Корінь: дрейф плану оптимізатора; відмінності статистики; інша поведінка тимчасових таблиць; зміна використання collations/індексів.

Виправлення: зафіксуйте і порівняйте EXPLAIN/EXPLAIN ANALYZE (де доступно), оновіть статистику, додайте або відрегулюйте індекси, розгляньте підказки запитів тільки як останній аргумент.

3) Реплікація «працює», але відновлення після відмови ламається

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

Корінь: семантична невідповідність GTID; припущення змішаної топології; різні налаштування binlog.

Виправлення: оберіть один GTID‑універсум; стандартизуйте налаштування реплікації; тестуйте просування і приєднання під навантаженням у стейджингу.

4) Бекапи проходять, відновлення не вдається

Симптоми: джоб бекапу зелений; тест відновлення падає на фазі prepare або сервер не стартує.

Корінь: несумісність версій інструмент/сервер; неправильні прапори; невідповідність шифрування/стиснення; відсутні очікувані redo логи.

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

5) Раптовий зріст блокувань після міграції

Симптоми: зростання очікувань на блокування, дедлоки, падіння пропускної здатності при схожому наборі запитів.

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

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

6) Моніторинг ламається або показує нісенітницю

Симптоми: дашборди без метрик, експортери з помилками, алерти про «unknown variable».

Корінь: назви метрик та їх наявність відрізняються; конфігурація performance_schema інша; відмінності в привілеях.

Виправлення: оновіть експортери і запити; увімкніть потрібну інструментацію цілеспрямовано; припиніть збирати нестабільні внутрішні значення.

Три корпоративні міні‑історії з практики

Міні‑історія 1: інцидент через хибне припущення

Середньостатистична SaaS‑компанія вирішила «стандартизувати» бази. Один продукт працював на MariaDB, інший — на Percona Server. План звучав просто: перевести все на один движок, щоб on‑call команда могла припинити контекст‑свічі.

Команда міграції зосередилася на схемі й переміщенні даних. Вони перевірили, що додаток стартує, CRUD працює і проходять smoke‑тести. Вони припустили, що відновлення після відмови поводитиметься однаково, бо «це все MySQL».

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

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

Міні‑історія 2: оптимізація, що обернулася проти

Великий підрозділ перейшов від одного варіанта MySQL до іншого, щоб отримати кращу інструментацію продуктивності й менші латентності. Після відкату вони помітили зростання IO і гірші tail‑латентності. Отже вони зробили те, що часто роблять: почали «крутити ручки».

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

Приблизно добу пропускна здатність покращувалася. Потім був сплеск трафіку. Сервер почав зависати хвилеподібно: короткі періоди нормальної роботи, за якими йшли жахливі паузи, де все ставало в чергу. Корінна причина — патерн тиску flush/redo: вони пожертвували стабільною латентністю заради періодичних обвалів. Тюнінг посилив найгірший момент движка замість того, щоб його згладити.

Вони відкотили зміни, профілювали знову і виявили справжню регресію: кілька запитів перейшли на плани з великими тимчасовими таблицями. Виправлення індексів і шаблонів запитів зменшило IO більше, ніж будь‑які зміни буферів. «Оптимізація» була відволіканням і ледь не залишилась постійною, бо тимчасово виглядала добре.

Міні‑історія 3: нудна, але правильна практика, що врятувала день

Фінансова компанія мала правило, яке дратувало всіх: квартальні відпрацювання відновлення — не за бажанням. Кожне відпрацювання включало відновлення повного бекапу, застосування binlog до потрібного часу і запуск простого набору перевірок консистентності.

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

Оскільки відпрацювання пройшло до cutover, виправлення було банальним: зафіксувати версії, створити протестований образ бекапу і додати перевірку сумісності в CI, яка запускала невеликий цикл backup/prepare/restore при кожному підвищенні версії.

Місяцями потому стався реальний інцидент: випадкове видалення даних. Команда відновилася чисто, применила binlog до хвилини і повернула сервіс без імпровізацій. Ніхто не святкував, бо це було нудно. Це найвища похвала в операціях.

Практичні завдання (команди + виводи + рішення)

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

Завдання 1: Підтвердіть ідентичність сервера та лінію версій

cr0x@server:~$ mysql -NBe "SELECT VERSION(), @@version_comment, @@version_compile_machine;"
10.11.6-MariaDB MariaDB Server x86_64

Що це означає: Це показує, яке сімейство ви насправді запускаєте. @@version_comment часто містить «Percona Server» або «MariaDB Server».

Рішення: Зіставте ціль сумісності. Якщо ви очікували семантику MySQL/Percona, а бачите MariaDB — зупиніться і повторно перевірте припущення про GTID, JSON і плагіни.

Завдання 2: Перевірте дрейф SQL‑mode (мовчазна зміна поведінки)

cr0x@server:~$ mysql -NBe "SELECT @@sql_mode;"
STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

Що це означає: SQL‑mode впливає на валідацію даних, неявні перетворення і обробку помилок.

Рішення: Уніфікуйте SQL‑mode між старим і новим серверами перед порівнянням поведінки. Якщо ви змінюєте його під час міграції — ви міняєте семантику додатка.

Завдання 3: Повердження плагіна автентифікації за замовчуванням

cr0x@server:~$ mysql -NBe "SHOW VARIABLES LIKE 'default_authentication_plugin';"
default_authentication_plugin	mysql_native_password

Що це означає: Різні значення за замовчуванням можуть зламати старі клієнти.

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

Завдання 4: Перевірте плагіни, які реально використовують користувачі

cr0x@server:~$ mysql -NBe "SELECT user, host, plugin FROM mysql.user ORDER BY plugin, user LIMIT 10;"
app	%	mysql_native_password
repl	10.%	mysql_native_password

Що це означає: Навіть якщо значення за замовчуванням безпечне, конкретні користувачі можуть використовувати несумісні плагіни.

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

Завдання 5: Перевірте базові налаштування InnoDB і redo/flush

cr0x@server:~$ mysql -NBe "SHOW VARIABLES WHERE Variable_name IN ('innodb_flush_method','innodb_flush_log_at_trx_commit','innodb_buffer_pool_size');"
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	1
innodb_flush_method	O_DIRECT

Що це означає: Ці налаштування сильно впливають на латентність, надійність та поведінку IO.

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

Завдання 6: Перевірте формат бінлогу і рядкового образу

cr0x@server:~$ mysql -NBe "SHOW VARIABLES WHERE Variable_name IN ('log_bin','binlog_format','binlog_row_image');"
log_bin	ON
binlog_format	ROW
binlog_row_image	FULL

Що це означає: Це впливає на безпеку реплікації і сумісність.

Рішення: Для міграцій ROW + FULL — консервативний дефолт. Якщо змінюєте на MINIMAL для продуктивності, ретельно тестуйте downstream‑споживачів і реплікацію.

Завдання 7: Перевірте індикатори режиму GTID

cr0x@server:~$ mysql -NBe "SHOW VARIABLES LIKE '%gtid%';" | head
gtid_domain_id	0
gtid_strict_mode	ON
gtid_binlog_pos	0-1-12345

Що це означає: Ці змінні — індикатори GTID у стилі MariaDB (domain/server/sequence).

Рішення: Якщо ви переходите до/з MySQL/Percona GTID, плануйте трансляцію GTID або скидання топології. Не «літайте навмання» під час події відмови.

Завдання 8: Визначте відставання репліки й причину (IO vs SQL)

cr0x@server:~$ mysql -e "SHOW SLAVE STATUS\G" | egrep "Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master|Last_SQL_Error|Retrieved_Gtid_Set|Executed_Gtid_Set" -n
3:Slave_IO_Running: Yes
4:Slave_SQL_Running: Yes
32:Seconds_Behind_Master: 18
48:Last_SQL_Error:
78:Retrieved_Gtid_Set:
79:Executed_Gtid_Set:

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

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

Завдання 9: Захопіть топ очікувань швидко (проксі для InnoDB mutex/lock pressure)

cr0x@server:~$ mysql -NBe "SHOW GLOBAL STATUS LIKE 'Innodb_row_lock%';"
Innodb_row_lock_current_waits	3
Innodb_row_lock_time	89123
Innodb_row_lock_time_avg	1123
Innodb_row_lock_time_max	9000
Innodb_row_lock_waits	79

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

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

Завдання 10: Визначте найдовше працюючі транзакції

cr0x@server:~$ mysql -e "SELECT trx_id, trx_started, trx_mysql_thread_id, trx_rows_locked, trx_rows_modified FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 5;"
+--------+---------------------+--------------------+----------------+------------------+
| trx_id | trx_started         | trx_mysql_thread_id| trx_rows_locked| trx_rows_modified|
+--------+---------------------+--------------------+----------------+------------------+
| 123ABC | 2025-12-30 01:12:09 | 9821               | 44012          | 12               |
+--------+---------------------+--------------------+----------------+------------------+

Що це означає: Довгі транзакції утримують блокування і збільшують обсяг роботи undo/redo.

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

Завдання 11: Порівняйте плани запитів для відомого «гарячого» запиту

cr0x@server:~$ mysql -e "EXPLAIN SELECT * FROM orders WHERE customer_id=123 AND status='OPEN' ORDER BY created_at DESC LIMIT 50;"
+----+-------------+--------+------+------------------------+--------------------+---------+-------+------+-----------------------------+
| id | select_type | table  | type | possible_keys          | key                | key_len | ref   | rows | Extra                       |
+----+-------------+--------+------+------------------------+--------------------+---------+-------+------+-----------------------------+
|  1 | SIMPLE      | orders | ref  | idx_customer_status_dt | idx_customer_status_dt | 8   | const | 120  | Using where; Using filesort |
+----+-------------+--------+------+------------------------+--------------------+---------+-------+------+-----------------------------+

Що це означає: «Using filesort» може бути нормальним — або це може бути ваш новий вузький місць, якщо раніше його не було.

Рішення: Якщо план змінився — розгляньте покривний індекс для підтримки ORDER BY. Перевіряйте реальну латентність і rows examined, а не лише вигляд EXPLAIN.

Завдання 12: Перевірте поведінку тимчасових таблиць та спади на диск

cr0x@server:~$ mysql -NBe "SHOW GLOBAL STATUS LIKE 'Created_tmp%';"
Created_tmp_disk_tables	12409
Created_tmp_tables	70211
Created_tmp_files	88

Що це означає: Тимчасові таблиці на диск і тимчасові файли часто корелюють із раптовими уповільненнями після змін оптимізатора.

Рішення: Якщо тимчасові таблиці на диск стрибнули після міграції — спочатку зосередьтесь на планах запитів і індексах. Тільки потім розгляньте зміни розмірів тимчасових таблиць.

Завдання 13: Підтвердіть значення за замовчуванням набору символів і колації

cr0x@server:~$ mysql -NBe "SHOW VARIABLES WHERE Variable_name IN ('character_set_server','collation_server');"
character_set_server	utf8mb4
collation_server	utf8mb4_general_ci

Що це означає: Зміни колації можуть порушити припущення про унікальність та використання індексів.

Рішення: Якщо значення за замовчуванням відрізняються від вашого baseline — встановіть їх явно і перевірте очікування додатка (особливо щодо сортування і регістрозалежності).

Завдання 14: Перевірте затримки IO файлової системи (реальність на хості)

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server) 	12/30/2025 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          32.10    0.00    6.20    7.80    0.00   53.90

Device            r/s     w/s   r_await   w_await   aqu-sz  %util
nvme0n1         220.0   480.0     2.10     8.70     4.20   92.0

Що це означає: Високі w_await і %util вказують на тиск записів. Міграції часто змінюють шаблони запису (інше поводження redo/log, інша поведінка тимчасових таблиць).

Рішення: Якщо сховище насичене — припиніть «тюнінг бази» і виправте IO‑ємність або зменшіть write amplification (виправлення запитів/індексів, батчування, зміни flush‑налаштувань лише з урахуванням надійності).

Завдання 15: Швидка перевірка параметрів монтування файлової системи, що саботують бази

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS /var/lib/mysql
/var/lib/mysql ext4 rw,relatime

Що це означає: Деякі опції монтування впливають на латентність. relatime зазвичай в порядку; інші опції (або мережеві файлові системи) можуть ні.

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

Завдання 16: Підтвердіть вирівнювання версій інструменту бекапу і сервера

cr0x@server:~$ xtrabackup --version
xtrabackup version 8.0.35 based on MySQL server 8.0.35 Linux (x86_64)

Що це означає: Інструменти бекапу рекламують свою ціль сумісності. Несумісність — це майбутня помилка відновлення.

Рішення: Зафіксуйте версію інструменту під те, що ви запускаєте. Якщо ви на MariaDB — віддавайте перевагу mariabackup, вирівняному з вашою гілкою MariaDB.

Чеклісти / покроковий план

План A: Ви обираєте Percona Server, бо потрібна справжня сумісність з MySQL

1. Інвентаризація очікувань додатка: матриця підтримки від постачальника, використовувані SQL‑функції (JSON, оконні функції, GENERATED COLUMNS) та версії клієнтських бібліотек.
2. Уніфікація SQL‑mode і набору символів: встановіть явні значення; не успадковуйте значення за замовчуванням.
3. Рішення про модель реплікації: оберіть семантику GTID і дотримуйтеся її. Не змішуйте MariaDB GTID із MySQL GTID у steady state.
4. Аудит інструментів: моніторинг, скрипти бекапу, автоматизація відмови, інструменти міграції схем — протестуйте їх на цільовому движку.
5. Базова продуктивність: зафіксуйте топ‑запити, p95/p99, rows examined, частоту тимчасових таблиць, хіти buffer pool.
6. Dry‑run відновлення: зробіть повне відновлення з бекапів в ізольованому середовищі і пройдіть перевірки консистентності.
7. Покроковий cutover: dual‑write, якщо можна обґрунтувати; інакше використовуйте просування репліки і відпрацьований план відкату.

План B: Ви обираєте MariaDB, бо берете на себе її екосистему

1. Припиніть називати це «MySQL» внутрішньо: маркуйте як MariaDB у рукбуках і дашбордах. Це зменшить хибні припущення.
2. Підтвердіть використання функцій: якщо ви залежите від MySQL 8‑специфічної семантики — будьте обережні. Тестуйте точну версію MariaDB, яку плануєте запускати.
3. Прийміть рідні інструменти MariaDB: особливо для бекапу/відновлення і автоматизації на основі GTID.
4. Перевірте використання JSON: перевірте типи колонок і очікування індексування; не припускайте нативної поведінки JSON, якщо приходите з MySQL.
5. Перетюньте під своє сховище: особливо поведінку тимчасових таблиць і патерни скидання; не переносіть конфіги як змінні середовища контейнера.
6. Відпрацювання відмови: симулюйте втрату вузла, просування і приєднання. Зробіть це двічі: спочатку в спокійному режимі, потім під навантаженням.

Мінімальні критерії прийняття «без сюрпризів» при міграції

• Ви можете відновити на новий хост і сервер чисто завантажиться.
• Відновлення після відмови працює, і репліки приєднуються без ручного втручання.
• Топ‑20 запитів мають стабільні плани й прийнятну хвостову латентність.
• Моніторинг і алертинг працюють без шуму про «unknown variable».
• Аутентифікація клієнтів і TLS працюють для всіх варіантів клієнтів у продакшені.

FAQ

1) Чи є Percona Server повноцінною заміною для MySQL?

Зазвичай — так, у межах тієї самої мажорної гілки MySQL — бо він тісно слідує upstream MySQL. Все одно перевіряйте плагіни, значення за замовчуванням і інструменти бекапу.

2) Чи є MariaDB повноцінною заміною для MySQL?

Іноді для базових додатків — так, але з підвищеним ризиком у міру розвитку MySQL. Якщо вам потрібна «поведінка MySQL 8», ставтеся до MariaDB як до іншої СУБД і тестуйте відповідно.

3) Чи є MariaDB повноцінною заміною для Percona Server?

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

4) Чи можна реплікувати з Percona Server на MariaDB (або навпаки)?

Іноді це можливо як тимчасовий міст із жорсткими обмеженнями (формат binlog, підтримуваний SQL, обережне планування GTID). Не припускайте, що це безпечно для довгострокової роботи без явної валідації.

5) Яка найбільша прихована пастка при міграції MariaDB ↔ Percona?

GTID і семантика відновлення після відмови. Це не SQL. Це те, що відбувається о 2:00, коли вузол впав і ваша автоматизація робить припущення.

6) Чи можна копіювати my.cnf налаштування з одного на інший?

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

7) Яка з них швидша?

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

8) Чи потрібні різні інструменти бекапу?

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

9) Як обрати, якщо мій постачальник лише каже «MySQL»?

Запитайте, що саме вони мають на увазі: версію, очікуваний плагін автентифікації, використання GTID, очікування щодо бекапу. Якщо вони тестували проти Oracle MySQL 8, Percona Server for MySQL 8 зазвичай безпечніший вибір.

10) Чи можна уникнути цих проблем, використовуючи контейнери і Kubernetes?

Ні. Контейнери чудово пакують сюрпризи консистентно. Вам все одно потрібна поведінкова сумісність, протестовані бекапи і відпрацьоване відновлення після відмови.

Наступні кроки, які можна зробити цього тижня

1. Запустіть практичні завдання на вашому поточному флоті і запишіть результати: версія, SQL‑mode, плагіни автентифікації, формат binlog, змінні GTID.
2. Оберіть єдину ціль сумісності: «MySQL 8 семантика» (нахил до Percona) або «MariaDB семантика» (коміт до MariaDB). Припиніть сподіватися, що отримаєте обидва задарма.
3. Зробіть одне відпрацювання відновлення на ізольованому хості і доведіть, що сервер стартує, а додаток може виконати невелике навантаження.
4. Відпрацюйте відновлення після відмови у стейджингу з тією ж автоматизацією, яку плануєте для продакшену. Якщо автоматизації немає — ваш перший відкат буде живим експериментом.
5. Зніміть базу і порівняйте плани для ваших топ‑запитів. Якщо знаходите регресії — виправляйте запити й індекси до того, як чіпати «ручки тюнінгу».

Якщо вам потрібне просте правило: Percona Server загалом безпечніший вибір як «MySQL‑сумісний»; MariaDB — солідна СУБД, коли ви ставитеся до неї як до MariaDB і припиняєте вдавати, що це просто MySQL з іншим логотипом.