MariaDB 11.8 є довгостроковою гілкою, що отримує планові виправлення після GA у червні 2025 року. Серед помітних змін — векторний тип і пошук, оновлення оптимізатора та функції, накопичені після LTS 11.4. Перехід потребує реальних планів запитів, а не лише проходження синтаксичних тестів.
Vector Search увійшов до LTS-гілки
MariaDB може зберігати вектори й будувати індекси для пошуку найближчих сусідів. Це зручно для невеликих семантичних сценаріїв, але точність, розмір індексу та час оновлення треба вимірювати на власних embeddings.
Оптимізатор може вибрати інший план
Нові правила й оцінки здатні прискорити запит або проявити слабкість неточних статистик. Збережіть EXPLAIN для критичних операцій до оновлення та порівняйте кількість рядків, порядок join і використання індексів.
Сумісність клієнта не дорівнює сумісності SQL
Драйвер може успішно під’єднатися, але ORM, stored procedures, collation чи sql_mode поводитимуться інакше. Перевіряйте не тільки connection test, а повний набір читання, запису, транзакцій і міграцій.
Реплікацію потрібно тестувати в обидва боки
Під час rolling upgrade стара й нова версії тимчасово співіснують. Команда має перевірити формат binlog, GTID, failover і можливість повернення. Відновлення старого вузла з новішого backup може бути непідтримуваним.
LTS не скасовує patch-оновлень
Довгострокова підтримка означає стабільну лінію супроводу, а не незмінний перший реліз. У production слід встановлювати актуальний corrective release гілки 11.8 і читати його release notes.
Чекліст міграції
- виконайте логічну й фізичну копії;
- перевірте відновлення;
- порівняйте плани запитів;
- оновіть драйвери;
- відтворіть реплікацію;
- виміряйте vector indexes;
- розгортайте через canary-вузол.
Нова функція не замінює проєктування даних
Матеріал TechPulse про обслуговування індексів допоможе побудувати вимірювання, а стаття про міграції без зупинки — спланувати rollout.
LTS-реліз потрібно оцінювати за власним профілем запитів
Статус довготривалої підтримки не гарантує, що оптимізатор поводитиметься однаково для вашої схеми. Збережіть slow query log, плани ключових запитів, статистику таблиць, розмір буферів і плагіни. На staging відновіть репрезентативні дані та порівняйте EXPLAIN, latency, тимчасові таблиці й IO. Особливу увагу приділіть запитам із нетиповою кардинальністю та залежністю від конкретного індексу.
Векторний пошук має власну модель якості
Визначте модель embedding, розмірність, метрику відстані, нормалізацію та спосіб оновлення векторів. Порівнюйте recall@k, latency, пам’ять та час побудови індексу на реальному наборі, а не лише на випадкових числах. Зміна моделі робить старі й нові вектори непорівнюваними, тому version зберігайте разом із записом. Для retrieval-систем додайте оцінювання з матеріалу про RAG у production.
Реплікацію перевіряють під змішаними версіями
Уточніть підтримуваний шлях переходу й порядок оновлення primary/replica. На тестовому кластері відтворіть write load, failover, lag, restart і backup. Не вмикайте нову функцію, доки репліки старої версії повинні читати відповідні дані. Для Galera окремо перевірте сумісність, quorum, SST/IST і поведінку клієнтів під зміною primary. Результат має містити реальний час відновлення.
Клієнти й ORM входять до міграції
Перевірте драйвери, connection pools, TLS, prepared statements, кодування, часові зони та session variables. Оновлена база може бути стабільною, але старий конектор неправильно оброблятиме нову автентифікацію або тип. Запустіть contract tests для кожного сервісу й виміряйте retry під короткою недоступністю. Неконтрольований повтор запису може створити дублікати або шторм з’єднань.
Розгортайте поетапно з перевіреним відновленням
До maintenance window виконайте backup і відновіть його на чистому середовищі. Оновіть репліку або canary, порівняйте метрики, а потім переводьте трафік хвилями. Умовами відкату є replication error, неприйнятна зміна плану, пошкодження даних або нестабільність клієнта. Після міграції оновіть automation, образи й runbook; старі пакети приберіть лише після завершення періоду спостереження.
Чекліст приймання MariaDB 11.8
Підтвердьте schema, users, grants, TLS, replication, backup/restore, events, procedures, plugins і всі критичні запити. Порівняйте row counts, checksums та плани. Для vector workload окремо виміряйте recall, latency, index build і memory після restart. Новий індекс не повинен погіршувати звичайні транзакції або блокувати тривале обслуговування.
Після переключення спостерігайте connection errors, deadlocks, replication lag, buffer pool, disk latency та slow queries. Кожна регресія має посилання на baseline й query ID. Оновіть клієнтські бібліотеки та automation, видаліть тимчасові сумісні параметри за графіком. Перевірений restore на чистому вузлі завершує міграцію краще, ніж сам факт успішного startup.
Коли LTS-статус не виправдовує негайний upgrade
Відкладіть перехід, якщо критичний plugin, driver або replication topology не підтримані й немає перевіреного обхідного шляху. Не маскуйте проблему вимкненням перевірки TLS або цілісності. Виняток має обмежений строк і захисні оновлення поточної версії.
Go-рішення підтверджує не лише startup, а відтворений backup, failover і типове пікове навантаження. Векторний пошук оцінюється окремо: його користь не повинна бути умовою безпечного базового оновлення СУБД.
Першоджерело: оголошення MariaDB 11.8 LTS та календар підтримки MariaDB.
Коментарі
Щоб залишити коментар, увійдіть через Google.