MariaDB проти RDS MariaDB: у кого менше дивних сюрпризів сумісності?

Тезис: хто вас менше дивуватиме

Якщо ви хочете менше сюрпризів сумісності, відповідь залежить від того, що ви вкладаєте в поняття «сумісність».
Якщо під цим ви маєте на увазі «БД поводиться точно як мій попередній сервер», перемога за self-managed MariaDB — бо ви контролюєте все оточення.
Ті самі пакунки, та сама файлова система, ті самі плагіни, ті самі init‑скрипти, той самий kernel, ті самі параметри.

Якщо ж ви маєте на увазі «вона продовжує працювати під час оновлень, апаратних збоїв і бекапів без необхідності вигадувати нову релігію», RDS MariaDB
менше дивуватиме вас в операційному сенсі, бо це продукт із захисними бар’єрами. Але ці бар’єри — теж поверхня сумісності:
parameter groups, обмежені плагіни, поведінка керованого сховища, керовані оновлення, обмежені привілеї SUPER і інший
підхід до моніторингу та відновлення після краху.

Практичні поради на основі думки:

• Обирайте self-managed MariaDB, коли ваша навантаження залежить від конкретних плагінів, поведінки файлової системи,
  кастомних збірок або точного тюнінгу (і у вас є досвідчені люди на виклику, які це підтримуватимуть).
• Обирайте RDS MariaDB, коли ваш головний біль — це операційна рутина (патчинг, бекапи, відновлення, сховище),
  і ваш застосунок дисципліновано ставиться до SQL‑поведінки, міграцій і тестування.

Сюрпризи сумісності не випадкові. Вони концентруються навколо привілеїв, плагінів, SQL‑режимів, налаштувань реплікації,
дефолтних charset/collation і «невидимої» інфраструктури: сховище, обмеження I/O та подій обслуговування.

Що насправді означає «сумісність» в продакшні

Сумісність — це не просто «запустилось» або «схему завантажено». У реальних системах ви дізнаєтесь, що сумісності немає, коли:
запити повертають тонко відмінні результати, реплікація розходиться, міграція зависає через metadata locks, побудова індексу підіймає I/O,
або патч безпеки змінює поведінку автентифікації і половина клієнтів падає.

Я ділю сюрпризи сумісності на п’ять груп:

1. Семантика SQL: sql_mode, зміни оптимізатора, дефолтні колації, поведінка JSON, віконні функції, граничні перетворення.
2. Модель привілеїв: еквіваленти SUPER, DEFINER‑об’єкти, адміністрування реплікації, встановлення плагінів, доступ до файлів.
3. Функціональні можливості сервера: плагіни, аудит, шифрування, хуки бекапу, налаштування performance_schema.
4. Зв’язок з інфраструктурою: підсистема сховища, поведінка fsync, ліміти IOPS, сітеві перебої, поведінка при відмові.
5. Життєвий цикл: оновлення версій, мажорні/мінорні релізи, дрейф параметрів, вікна технічного обслуговування, автоматичний failover.

Груба реальність: RDS MariaDB — це «MariaDB з обгорткою продукту». Self-managed MariaDB — це «MariaDB з тим, що ви навколо неї побудували».
Ваші сюрпризи приходять від обгортки або від власного glue‑коду — обирайте свій біль.

Історичний контекст і факти, що пояснюють сучасні дивності

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

• Факт 1: MariaDB відокремилась від MySQL після поглинання Sun компанією Oracle. Цей форк створив довготривалу реальність «переважно сумісно, поки не перестане бути».
• Факт 2: Нумерація версій MariaDB не відображається прямо в часовій шкалі функцій MySQL. «10.x» — це не «MySQL 10», це власна лінійка.
• Факт 3: MariaDB з часом підключала альтернативні двигуни і функції (наприклад, Aria, інша робота оптимізатора). Це важливо для крайових випадків і продуктивності.
• Факт 4: AWS RDS — це не VM, в який ви маєте root‑доступ. Це керована служба з кураторним набором параметрів і підтримуваних плагінів.
• Факт 5: У RDS є спеціальний «master» користувач, який схожий на root, але ним не є; певні привілеї і файлові операції навмисно заблоковані.
• Факт 6: MySQL 8 змінив дефолтну автентифікацію та колації, чим навчив індустрію: «дефолти — приховані бекамінгові зміни». MariaDB теж має свої зсуви дефолтів між мажорними версіями.
• Факт 7: Сховище RDS абстраговане; ваша I/O‑виробність визначається типом EBS, ресурсами IOPS, поведінкою бурсту та «шумними сусідами», а не вашим улюбленим RAID‑контролером.
• Факт 8: У керованих сервісах мінорні патчі можуть включати зміни поведінки, яких ви не замовляли, бо оновлення виходять, коли AWS їх сертифікує.
• Факт 9: Реплікація MariaDB має кілька режимів і варіантів GTID; змішування flavor‑ів між середовищами може створити дивності реплікації, які виглядають як корупція, але насправді це дрейф конфігурації.

Цитата, яка лишається актуальною, бо бази даних — це просто розподілені системи у тренч‑коуті:
Надія — це не стратегія. — генерал Gordon R. Sullivan

Звідки беруться сюрпризи сумісності (реальні категорії)

1) Привілеї: ілюзія «я root»

На self-managed MariaDB, якщо у вас є root на хості і користувач з усіма привілеями, ви зазвичай можете робити все:
встановлювати плагіни, читати/писати файли для LOAD DATA INFILE, встановлювати глобальні змінні, копирсатися в інтернах реплікації.

На RDS MariaDB master‑користувач потужний, але не всемогутній. AWS блокує певні операції, бо клієнти, що ділять
керовану інфраструктуру, не повинні мати можливість «зламає» хост або викрасти дані інших орендарів. Ви побачите це як помилки типу:
«Access denied; you need (at least one of) the SUPER privilege» або «File not found», хоча файл «існує» у вашій уяві.

2) Плагіни: ваш улюблений плагін — чиєсь інше інцидентне джерело

Self-managed MariaDB дозволяє запускати все, що вам потрібно: плагіни аудиту, кастомні плагіни автентифікації, хелпери для бекапу/відновлення,
додаткову інструментацію продуктивності.

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

Жарт №1 (короткий, доречний): Хмара дає вам допоміжні колеса, а потім стягує плату за кожну годину за привілей їх не знімати.

3) SQL‑режими, колації і запити «працювали на моєму ноуті»

Більшість вибухів сумісності — самозаподіяні. Різні дефолти для sql_mode, character_set_server
і collation_server можуть перетворити поблажливу поведінку в розробці на суворі продакшен‑помилки — або, гірше, на мовчазне обрізання та відмінності сортування.

RDS може постачатися з дефолтами, що відрізняються від ваших он‑прем пакетів. І навіть якщо дефолти однакові сьогодні, оновлення движка може їх змістити.
Self-managed середовища теж оновлюються, але ви зазвичай контролюєте час і перевірку збірки.

4) Семантика сховища: IOPS, fsync і фізика, з якою не домовишся

Якщо ви запускаєте MariaDB на власних хостах, ви контролюєте розкладку дисків, файлову систему, опції монтування, політику кешування RAID
і те, чи ваші налаштування „durability“ введені в оману. Ви також несете наслідки.

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

5) Обслуговування та failover: планові події, що поводяться як непланові

RDS проводить обслуговування. Іноді ви обираєте вікно; іноді AWS обирає його за вас, якщо ви відстали з патчами безпеки.
Ви також живете з семантикою failover: розриви з’єднань, зміни DNS і невелике вікно, коли ваш застосунок або перепідключається правильно, або горить.

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

Self-managed MariaDB: менше захисних бар’єрів, менше невидимих обмежень

Профіль сумісності self-managed MariaDB — «те, що ви побудували, те й отримаєте». Це одночасно найкраща і найгірша риса.
Якщо ваш застосунок очікує конкретний набір поведінки — кастомні плагіни, певні патерни доступу до файлової системи, налаштований InnoDB,
або строгий топологічний підхід до реплікації — ви можете це забезпечити.

Де self-managed найменше дивує

• Доступність плагінів: ви можете встановлювати потрібні плагіни, тестувати їх і зафіксувати версії.
• Доступ до файлової системи: LOAD DATA INFILE, SELECT ... INTO OUTFILE і локальні файлові сценарії працюють передбачувано.
• Налаштування на рівні ОС: THP, swappiness, I/O scheduler, опції монтування файлової системи, NUMA‑pinning — все це може бути важливим у крайових навантаженнях.
• Точний контроль версій: ви можете відкладати «мінорні» оновлення, що змінюють поведінку, доки не проведете валідацію.

Де self-managed призводить до гірших сюрпризів

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

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

RDS MariaDB: керована надійність з керованими обмеженнями

RDS MariaDB — для команд, які хочуть припинити роль «постачальник сховища» на собі. Бекапи, автоматичне патчування, інтеграція моніторингу
та failover вбудовані. Це усуває цілі класи операційних відмов.

Де RDS менше дивує

• Бекапи та процедури відновлення: акорди знімків працюють послідовно і протестовані в масштабі.
• Апаратні та проблеми зі сховищем: це проблема AWS (хоча ваш простій все одно ваша відповідальність).
• Базовий моніторинг: CloudWatch‑метрики та RDS‑події дають сигнали, навіть якщо ваш стек моніторингу тонкий.
• Стандартизоване управління параметрами: менше конфігів, змінених вручну на різних хостах.

Де RDS частіше дивує

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

Жарт №2 (короткий, доречний): Нічого так не змушує цінувати керовані бекапи, як усвідомлення, що ваш «сервер для бекапів» — це ще й інтерновий Minecraft‑хост.

Матриця сумісності: що найчастіше відрізняється

Автентифікація та сумісність клієнтів

Більшість збоїв клієнтів не екзотичні. Це старі конектори, TLS‑налаштування або дефолти автентифікації. Self-managed дозволяє
точно відтворити старе оточення; RDS штовхає вас до рекомендованих AWS‑безпечних налаштувань, іноді швидше, ніж ви оновите застосунок.

Правило прийняття рішення: якщо у вас є застарілі клієнти, які ви не можете швидко оновити, self-managed дає вам час. Якщо ви можете оновити клієнтів і вимагати TLS,
RDS зазвичай знижує довгострокові ризики.

Реплікація і GTID‑смак

GTID у MariaDB не те саме, що GTID у MySQL. І «сумісна реплікація» ≠ «ідентична реплікація». При переході між середовищами потрібно зафіксувати:
binlog_format, gtid_domain_id, gtid_strict_mode, рядкові vs statement семантики і як ваші інструменти читають позиції.

RDS підтримує функції реплікації, але ви керуєте ними через API і збережені процедури, а не через повний доступ до ОС.
Операційний робочий процес змінюється, і сюрпризи виникають частіше через цю зміну, ніж через сам MariaDB.

SQL‑режими і суворість

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

Таймзони, локалі і «вчора було добре»

Інстанси RDS працюють на керованих OS‑образах. Ваші self‑managed хости можуть мати кастомний tzdata або інший процес завантаження таблиці часових зон.
Міграції, що зачіпають таймстампи або конвертацію дат, коли це проявляється.

Характеристики продуктивності сховища

На self‑managed ви можете перепризначити RAM, закріпити буфери, страйпити диски і тюнити I/O‑стек. На RDS ви купуєте клас інстансу
і профіль тому. Обидва підходи працюють; обидва можуть дивувати.

Схема сюрпризів послідовна: спайкові навантаження або великі сплески чекпоінтів поводяться по‑різному на різних бекендах сховища.
Якщо система чутлива до хвостової латентності, тестуйте під навантаженням, а не «smoke test на п’яти користувачах».

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

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

Середньої величини SaaS‑компанія вирішила перемістити звітне навантаження з self‑managed MariaDB до RDS MariaDB. Воно було «некритичне».
Саме так говорять люди перед тим, як воно стає критичним.

У них був пайплайн, який розміщував CSV на хості бази і використовував LOAD DATA INFILE для масового завантаження в staging‑таблиці.
На їхніх серверах процес лоадера писав у відому директорію, і DB‑користувач мав FILE‑привілей. Було нудно.

На RDS такий підхід уперся в стіну: база не могла читати довільні шляхи файлової системи хоста, і «master user»
не поводився як root. Вони намагалися грубо вирішити це через GRANT і ні до чого не дійшли. Тим часом таблиці звітів відставали,
дашборди брехали, а відділ продажів відкрив для себе, що «рішення на основі даних» — це здебільшого вайб.

Виправлення не було хитрим. Вони змінили механізм завантаження на підтримуваний шлях: імпорт з боку застосунку через batch‑вставки
з адекватними розмірами транзакцій, а згодом переписали це в ETL‑джоб, який залишав дані в об’єктному сховищі і завантажував через підтримуваний робочий процес.
Урок не в тому, що RDS поганий. Урок у тому, що якщо ваш імпорт залежить від файлових семантик ОС — його треба перепроектувати перед міграцією.

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

Fintech‑команда запускала MariaDB на RDS і помітила періодичні спайки записів. Хтось запропонував збільшити паралелізм,
запустивши більше конкурентних писачів і піднявши декілька параметрів InnoDB у parameter group. Графіки покращилися на день.

Потім спайки стали гіршими, і нічна задача почала таймаути. Що змінилося? Поведінка чекпоінтингу і фонового флашу стала
більш сплескоподібною за нових налаштувань, а том сховища вже був біля свого реального горизонту IOPS у пікові години.
Замість згладжування вони підсилили contention.

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

Виправили відкатом найбільш агресивних налаштувань, закупівлею сховища з консистентними IOPS і зменшенням вибуховості писачів
шляхом зміни batching‑у в застосунку та винесення нічної задачі у вікно з меншим числам конкурентних записів. Найефективнішим «тапінгом БД»
виявилось саме формування навантаження.

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

Велика B2B‑платформа мала змішаний флот: деякі self‑managed MariaDB для спеціалізованих робочих навантажень і RDS MariaDB для більшості транзакційних систем.
Їхньою секретною зброєю не була хитра архітектура. Це була дисципліна.

Кожна міграція схеми проходила через суміснісне середовище тестування: міграція виконувалась у двох середовищах — «найбільш схоже self‑managed» і тестовому RDS — потім запускали набір планів запитів і перевірок коректності. Вони порівнювали виводи EXPLAIN,
шукали дрейф колацій і проганяли мінімальний replay продакшен‑запитів.

Якось тиждень тому мінорний оновлення движка в тестовому RDS змінило план оптимізатора для запиту, що використовував композитний індекс плюс range‑умову.
Це не було помилкою, просто повільніше. Хвіртка виявила це, вони додали цільовий індекс і відклали оновлення, доки не прийшло виправлення.
Продакшен ніколи не побачив регресії.

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

Практична діагностика: команди, виводи та рішення (12+)

Ось перевірки, які я реально запускаю, коли хтось каже «RDS MariaDB поводиться дивно» або «self‑managed працювало, а хмара проклята».
Кожне завдання містить: команду, що означає вивід, і рішення, яке з цього випливає.

Завдання 1: Визначити версію движка і дистрибуцію

cr0x@server:~$ mysql -h db.example.internal -u app -p -e "SELECT VERSION(), @@version_comment;"
Enter password:
+---------------------+----------------------------------+
| VERSION()           | @@version_comment                |
+---------------------+----------------------------------+
| 10.6.16-MariaDB     | MariaDB Server                   |
+---------------------+----------------------------------+

Значення: Ви на MariaDB 10.6.x. @@version_comment допомагає відрізнити вендорські збірки.
На RDS часто буде коментар, притаманний AWS.

Рішення: Побудуйте матрицю сумісності навколо точних major/minor. Не сперечайтесь про «10.6‑щось».

Завдання 2: Перевірити дрейф sql_mode

cr0x@server:~$ mysql -h db.example.internal -u app -p -e "SELECT @@GLOBAL.sql_mode, @@SESSION.sql_mode\G"
Enter password:
*************************** 1. row ***************************
@@GLOBAL.sql_mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
@@SESSION.sql_mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

Значення: Суворий режим увімкнений глобально і в сесії. Якщо у dev відмінно — отримаєте «в dev працює» вставки.

Рішення: Вирівняйте dev/test/prod sql_mode; розглядайте невідповідність як блокер релізу.

Завдання 3: Перевірити дефолтні charset/collation (тут живуть мовчазні баги)

cr0x@server:~$ mysql -h db.example.internal -u app -p -e "SHOW VARIABLES LIKE 'character_set_%'; SHOW VARIABLES LIKE 'collation_%';"
Enter password:
+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| character_set_client     | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database   | utf8mb4 |
| character_set_results    | utf8mb4 |
| character_set_server     | utf8mb4 |
| character_set_system     | utf8    |
+--------------------------+---------+
+----------------------+--------------------+
| Variable_name        | Value              |
+----------------------+--------------------+
| collation_connection | utf8mb4_general_ci |
| collation_database   | utf8mb4_general_ci |
| collation_server     | utf8mb4_general_ci |
+----------------------+--------------------+

Значення: Ви на utf8mb4 з певною колацією. Сортування і порівняння можуть відрізнятись між колаціями.

Рішення: Зафіксуйте charset/collation на рівні схеми і з’єднання; не покладайтеся на дефолти сервера.

Завдання 4: Виявити обмежені привілеї (поширено на RDS)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW GRANTS FOR CURRENT_USER();"
Enter password:
+--------------------------------------------------------------------------------------------------+
| Grants for admin@%                                                                                |
+--------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER... |
+--------------------------------------------------------------------------------------------------+

Значення: Ви бачите, що реально маєте, а не що вважаєте, що маєте. Відсутність SUPER‑подібних прав має значення.

Рішення: Якщо ваш runbook вимагає SUPER — перепишіть runbook під RDS‑робочі процеси (parameter groups, процедури, API).

Завдання 5: Підтвердити binlog формат і критичні для реплікації налаштування

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_format'; SHOW VARIABLES LIKE 'server_id';"
Enter password:
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 12345 |
+---------------+-------+

Значення: Бінлог увімкнено, формат ROW (зазвичай найбезпечніший для сумісності), і server_id задано.

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

Завдання 6: Виявити довгі транзакції і блокування

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW FULL PROCESSLIST;"
Enter password:
+----+------+-------------------+------+---------+------+----------------------+-------------------------------------------+
| Id | User | Host              | db   | Command | Time | State                | Info                                      |
+----+------+-------------------+------+---------+------+----------------------+-------------------------------------------+
| 88 | app  | 10.0.1.22:51344   | prod | Query   | 312  | Waiting for metadata | ALTER TABLE orders ADD COLUMN foo INT     |
| 91 | app  | 10.0.2.18:60112   | prod | Query   | 305  | Sending data         | SELECT ... FROM orders JOIN ...           |
+----+------+-------------------+------+---------+------+----------------------+-------------------------------------------+

Значення: DDL чекає на metadata locks поки довгі запити працюють. Це виглядає як «міграція застрягла».

Рішення: Вбити блокер або перенести міграцію; впровадити online schema change інструменти для великих таблиць.

Завдання 7: Перевірити стан InnoDB щодо дедлоків і тиску на флаш

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,120p'
Enter password:
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2025-12-30 10:12:41 0x7f8c1c1
LATEST DETECTED DEADLOCK
------------------------
...snip...
LOG
---
Log sequence number          8876543210
Log flushed up to            8876543210
Last checkpoint at           8876400000
0 pending log flushes, 0 pending chkp writes

Значення: Дедлоки і статус чекпоінтів показують, чи ви обмежені I/O або блокуванням.

Рішення: Якщо чекпоінти відстають і черга flush зростає, зосередьтеся на сховищі/IOPS і схемі записів — не тільки на тюнінгу запитів.

Завдання 8: Знайти топ очікувань і запитів (Performance Schema)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 AS seconds_waited FROM performance_schema.events_waits_summary_global_by_event_name ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;"
Enter password:
+----------------------------------------+------------+----------------+
| EVENT_NAME                             | COUNT_STAR | seconds_waited |
+----------------------------------------+------------+----------------+
| wait/io/file/innodb/innodb_data_file   |   18233412 |          913.2 |
| wait/io/file/innodb/innodb_log_file    |    8234411 |          402.7 |
| wait/synch/mutex/innodb/buf_pool_mutex |    2234410 |          188.5 |
| wait/lock/table/sql/handler            |     834411 |           72.1 |
| wait/synch/mutex/sql/LOCK_open         |     244110 |           41.0 |
+----------------------------------------+------------+----------------+

Значення: Сильні очікування файлового I/O свідчать про вузьке місце I/O; очікування mutex вказують на внутрішню конкуренцію.

Рішення: Якщо домінує I/O, припиніть бездумно змінювати індекси; спочатку збільшіть IOPS або зменшіть write amplification.

Завдання 9: Перевірити параметри, що часто відрізняються між середовищами

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_flush_log_at_trx_commit','sync_binlog','innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size');"
Enter password:
+--------------------------------+------------+
| Variable_name                  | Value      |
+--------------------------------+------------+
| innodb_buffer_pool_size        | 17179869184|
| innodb_flush_log_at_trx_commit | 1          |
| max_connections                | 2000       |
| max_heap_table_size            | 67108864   |
| sync_binlog                    | 1          |
| tmp_table_size                 | 67108864   |
+--------------------------------+------------+

Значення: Налаштування durability 1/1 безпечні, але можуть бути повільнішими на обмеженому I/O. Розміри тимчасових таблиць впливають на спільний диск.

Рішення: Не «оптимізуйте» durability заради продуктивності, якщо ви не готові пояснювати втрату даних керівництву.

Завдання 10: Виявити spill‑и у тимчасові таблиці (плани запитів, що поводяться інакше)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Created_tmp%tables';"
Enter password:
+-------------------------+--------+
| Variable_name           | Value  |
+-------------------------+--------+
| Created_tmp_disk_tables | 123456 |
| Created_tmp_files       | 8421   |
| Created_tmp_tables      | 987654 |
+-------------------------+--------+

Значення: Велика кількість disk tmp tables означає, що запити виливаються на диск — часто через сортування/групування або недостатні tmp розміри.

Рішення: Тюньте запити і індекси; обережно збільшуйте tmp розміри; перевірте, чи сховище RDS витримає патерни spill.

Завдання 11: Перевірити статус логування повільних запитів (відслідковування регресій)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES LIKE 'slow_query_log%'; SHOW VARIABLES LIKE 'long_query_time';"
Enter password:
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| slow_query_log      | ON    |
| slow_query_log_file | /rdsdbdata/log/slowquery/mysql-slowquery.log |
+---------------------+-------+
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| long_query_time | 1.000 |
+-----------------+-------+

Значення: Slow query log увімкнено, поріг 1с, шлях файлу вказує на розташування в керованому сховищі RDS.

Рішення: Якщо ви літали в сліпоту — увімкніть slow logging у непікові вікна і робіть семпли; не гадіть.

Завдання 12: Перевірити поведінку з’єднань і aborted connections

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Aborted_connects'; SHOW GLOBAL STATUS LIKE 'Threads_connected'; SHOW GLOBAL STATUS LIKE 'Max_used_connections';"
Enter password:
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_connects | 4821  |
+------------------+-------+
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 412   |
+-------------------+-------+
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 1987  |
+----------------------+-------+

Значення: Багато aborted connects можуть означати дрейф облікових даних, TLS‑невідповідності, шторм з’єднань під час failover або тиск на max_connections.

Рішення: Якщо з’єднання зростають під час деплоїв або failover — впровадьте pooling та backoff; не збільшуйте max_connections як першу реакцію.

Завдання 13: Підтвердити таблиці часових зон і серверний час

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES LIKE 'time_zone'; SELECT CONVERT_TZ('2025-12-30 12:00:00','UTC','America/Los_Angeles') AS converted;"
Enter password:
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| time_zone     | SYSTEM |
+---------------+--------+
+---------------------+
| converted            |
+---------------------+
| 2025-12-30 04:00:00 |
+---------------------+

Значення: Конвертація часових зон працює; таблиці завантажені. Якщо CONVERT_TZ повертає NULL, таблиці часових зон не завантажені.

Рішення: Виправте завантаження tz‑таблиць у self‑managed; у RDS використовуйте підтримувані процедури/шляхи і тестуйте часові обчислення явно.

Завдання 14: Порівняти DEFINER у схемних об’єктах (генератор сюрпризів при міграції)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SELECT ROUTINE_SCHEMA, ROUTINE_NAME, DEFINER FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA='prod' LIMIT 5;"
Enter password:
+---------------+-------------------+----------------+
| ROUTINE_SCHEMA| ROUTINE_NAME      | DEFINER        |
+---------------+-------------------+----------------+
| prod          | refresh_rollups   | root@localhost |
| prod          | prune_sessions    | root@localhost |
| prod          | calc_tax          | app@%          |
| prod          | rebuild_summary   | root@localhost |
| prod          | rotate_partitions | dba@%          |
+---------------+-------------------+----------------+

Значення: Рутини, створені від root@localhost, будуть проблемою на RDS і в будь‑якому середовищі, де такого користувача немає.

Рішення: Уніфікуйте DEFINER‑и і перебудуйте об’єкти під час міграції; не імпортуйте дамп бездумно.

Швидкий план діагностики: що перевірити першим/другим/третім

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

Перше: підтвердити, що це справді те саме навантаження і ті самі семантики

1. Дрейф версій і налаштувань: порівняйте VERSION(), sql_mode, charset/collation і ключові змінні InnoDB.
   Якщо вони відрізняються, зупиніться. Ви дебагуєте дві різні бази.
2. Перевірки привілеїв і DEFINER: запустіть SHOW GRANTS і проскануйте на невідповідності DEFINER. Якщо бракує прав і інструменти падають, ви витратите години, звинувачуючи «RDS».
3. Поведінка клієнта: перевірте помилки підключення і TLS‑налаштування. Failover більше виявляє крихкі клієнти, ніж баги БД.

Друге: вирішіть, CPU‑bound це, I/O‑bound чи lock‑bound

1. Lock‑bound: processlist показує «Waiting for metadata lock», «Waiting for table lock» або дедлоки в InnoDB status.
2. I/O‑bound: Performance Schema показує домінування file waits; InnoDB status — затримки чекпоінтів або flush pressure; зростають тимчасові таблиці на диску.
3. CPU‑bound: запити швидкі поодинці, але при конкуренції падає throughput; зростає mutex contention; метрики CPU насичені.

Третє: ізолюйте, чи різниця — це обгортка RDS чи ядро MariaDB

1. Обгортка: відсутність SUPER, неподтримувані плагіни, файлові обмеження, обмеження parameter group.
2. Ядро: зміни планів оптимізатора, семантика колацій, суворість, відмінності формату реплікації.
3. Інфраструктура: пропускна здатність сховища/IOPS, кредити бурсту, шумні сусіди, події обслуговування, failover.

Якщо ви зможете назвати, в якій з трьох корзин ви перебуваєте за 20 хвилин — ви вже попереду більшості «war room» сесій.

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

1) «На self‑managed працювало, RDS відкидає»

Симптоми: помилки про SUPER, FILE‑привілей, невдачі встановлення плагінів або неможливість читати/писати локальні файли.

Корінь проблеми: припущення, що RDS — це VM з root‑доступом і повними привілеями.

Виправлення: перепроєктуйте робочі процеси, щоб уникати залежності від файлової системи; використовуйте підтримувані імпорт/експорт патерни; замініть привілейовані операції на parameter groups і механізми від AWS.

2) «Той самий запит, інший порядок результатів»

Симптоми: ненадійна пагінація, непостійні ORDER BY‑вузли, інша поведінка сортування тексту.

Корінь проблеми: різниця колацій або покладання на невизначений порядок без явного ORDER BY.

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

3) «Реплікація зламалась під час міграції»

Симптоми: репліка зупиняється з помилками про GTID, binlog format або дублікати, яких «не має бути».

Корінь проблеми: невідповідність binlog_format (STATEMENT/MIXED vs ROW), різні налаштування GTID або недетерміновані оператори.

Виправлення: стандартизувати на ROW; вирівняти конфігурацію GTID; проаудитити недетерміновані функції і тригери.

4) «DDL‑міграції зависають назавжди»

Симптоми: ALTER TABLE застряг, накопичення запитів, раптові таймаути.

Корінь проблеми: metadata locks блокуються довгими запитами або транзакціями; інструмент міграції не online‑safe.

Виправлення: впровадьте online schema change підходи; скоротіть тривалість транзакцій; плануйте DDL‑вікна; знаходьте блокери через processlist.

5) «Продуктивність погіршилась після «мінорного» оновлення»

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

Корінь проблеми: зміни оптимізатора, відмінності статистик або дрейф параметрів.

Виправлення: порівняйте EXPLAIN плани до/після; освіжіть статистики; додайте цільові індекси; пропускайте оновлення через план‑диф тест.

6) «Підключення зростають під час failover і застосунок плавиться»

Симптоми: високі Aborted_connects, шторм з’єднань, таймаути після RDS failover або техобслуговування.

Корінь проблеми: клієнти не перепідключаються коректно; немає pooling; агресивні retry‑цикл.

Виправлення: додайте connection pooling; експоненційний backoff; знижуйте churn з’єднань; тестуйте поведінку при failover у репетиціях.

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

Чекліст A: Вибір між self-managed MariaDB і RDS MariaDB (орієнтир на сумісність)

1. Перелічіть залежності: плагіни, UDF, файлові навантаження, кастомна автентифікація, скрипти ОС.
2. Класифікуйте кожну залежність: «must‑have», «nice‑to‑have», «legacy, що треба видалити».
3. Перевірте вимоги до привілеїв: все, що потребує SUPER/FILE/OS‑доступу — це пункт перепроєктування для RDS.
4. Зафіксуйте поведінку SQL: sql_mode, charset, collation, поведінку часових зон.
5. Визначте план реплікації: binlog format, GTID‑режим, підхід cutover, стратегія відкату.
6. Визначте стратегію оновлень: хто погоджує, як ви тестуєте plan‑diff, і які метрики — «no‑go».

Чекліст B: План міграції, що мінімізує сюрпризи сумісності (підходить в обидві сторони)

1. Зробіть інвентар змінних сервера в джерелі й цілі; пропорівняйте їх і вирішіть навмисні відмінності.
2. Експортуйте тільки схему і проскануйте на DEFINER і SQL SECURITY; нормалізуйте користувачів/definer‑и.
3. Програйте репрезентативний набір запитів і порівняйте результати та таймінги, а не лише «без помилок».
4. Перевірте набори символів та колації на рівні таблиць і колонок; виправте дрейф до переносу даних.
5. Перевірте поведінку часових зон за допомогою CONVERT_TZ і граничних дат.
6. Тестуйте failover/reconnect з реальним застосунком і налаштуваннями пулера.
7. Практикуйте відновлення з снапшоту/ланцюга логів у тестовому середовищі; виміряйте RTO і перевірте коректність.
8. Перехід з планом відкату: dual writes, якщо можливо, або cutover через реплікацію з чітким планом revert.

Чекліст C: Day‑2 операції, що зменшують частоту сюрпризів

• Перiодично порівнюйте критичні змінні між середовищами (dev/stage/prod).
• Автоматизуйте перевірки регресій планів для топ‑запитів після оновлень.
• Підтримуйте slow query log і Performance Schema в робочому стані (семплі допомагають краще за сліпоту).
• Регулярно тестуйте відновлення і контрольований failover, навіть якщо це незручно.

Питання й відповіді

1) Хто загалом має менше сюрпризів сумісності?

Якщо ваш застосунок очікує повний контроль (плагіни, файлову систему, привілеї) — self‑managed MariaDB менше дивуватиме.
Якщо ваш застосунок портативний і дисциплінований, RDS менше дивуватиме вас в операціях — але ви маєте прийняти керовані обмеження.

2) Чи є RDS MariaDB «справжньою MariaDB»?

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

3) Який головний підводний камінь при міграції в RDS MariaDB?

Робочі процеси, що припускають доступ на рівні ОС: файлові імпорт/експорт, кастомні скрипти на хості БД, встановлення плагінів або операції, що вимагають SUPER.
Перепроєктуйте їх заздалегідь, до перенесення даних.

4) Чи можна покладатися на «мінорні оновлення безпечні» на будь‑якій платформі?

Ні. Мінорні оновлення можуть змінювати вибір оптимізатора, дефолти і граничну поведінку. Зазвичай вони безпечніші за мажорні,
але «зазвичай» — не контракт. Пропускайте оновлення через plan‑diff і реплікацію запитів.

5) Чи дійсно sql_mode має таке значення?

Так. SQL‑режими вирішують, чи погані дані відкидаються голосно або приймаються тихо і збережуться неправильно.
Сюрпризи сумісності часто виглядають як «БД змінилася», але насправді це просто суворіша перевірка коректності.

6) Чому продуктивність на RDS відчувається інакше при тій самій інстанс‑конфігурації?

Тому що семантика сховища й I/O відрізняються. Кероване сховище має ліміти, поведінку бурсту і ефекти шумних сусідів.
Також обмеження параметрів і фонового обслуговування можуть змінювати розподіл латентності.

7) Як уникнути помилок, пов’язаних з DEFINER, при міграціях?

Уніфікуйте definers на сервісний акаунт, який існує в усіх середовищах, і перевстановіть рутини/в’ю/тригери з цим definer.
Не імпортуйте дамп з root@localhost в середовище, де така ідентичність нічого не означає.

8) Чи варто використовувати ROW binlog format?

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

9) Чи завжди self‑managed більш «сумісний», бо ви контролюєте все?

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

10) Який найкращий спосіб протестувати сумісність перед переходом?

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

Висновок: практичні кроки далі

Якщо ви вирішуєте виключно на підставі «дивних сюрпризів сумісності», self‑managed MariaDB безпечніша, коли вам потрібна повна паритетність
з існуючою on‑prem або кастомною конфігурацією. Ви можете точно відтворити оточення. Ви також зможете точно відтворити ті самі помилки — це теж свого роду консистентність.

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

Наступні кроки, що реально зменшать кількість сюрпризів:

1. Зріз змінних сервера (sql_mode, charset/collation, binlog‑налаштування, InnoDB durability‑ручки) між джерелом і метою.
2. Проскануйте схему на DEFINER‑міни і нормалізуйте їх до міграції.
3. Виберіть історію реплікації (ROW + вирівняна GTID‑стратегія) і відрепетируйте cutover та відкат.
4. Запустіть harness перевірки планів і коректності перед оновленнями і перед переходами платформи. Зробіть це нудним. Нудність — це ціль.
5. Практикуйте відмови: тестуйте відновлення та failover з реальним застосунком. Якщо логіка клієнта для перепідключення крихка, RDS її проявить.

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