Что именно произошло 1 сентября
Формулировка у Битрикса аккуратная: «ограничена поддержка». Расшифровываю, как это работает на практике.
- С 1 февраля 2026 ограничена поддержка продуктов на PHP ниже 8.2. Рекомендуемая версия — PHP 8.4 и выше.
- С 1 сентября 2026 ограничена поддержка на MySQL ниже 8.0.0. Рекомендуемая версия — MySQL 8.4.0 и выше.
- Уведомление об этом висит в админке коробочных версий с февраля 2026-го — многие его просто закрывали.
Сайт на MySQL 5.7 первого сентября не выключился и ошибку не показал. Но с этой даты ядро и модули обновляются без проверки совместимости со старой базой. То есть очередное обновление безопасности может прийти с запросом, который MySQL 5.7 не понимает, — и вы узнаете об этом от клиентов, а не от Битрикса.
Отдельная деталь: сама ветка MySQL 8.0 у Oracle завершила жизненный цикл в апреле 2026 года. Поэтому «переехать на восьмёрку» сегодня означает переехать на 8.4 LTS, а не на 8.0. Подробности политики — в документации техподдержки.
Почему это не формальность
Я видел два типа отношения к таким объявлениям. Первый: «у нас всё работает, не трогаем». Второй: паника и переезд в ночь на пятницу без бэкапа. Оба заканчиваются одинаково — простоем.
Реальные риски старой базы:
- Обновления безопасности. Битрикс закрывает уязвимости регулярно, и патчи теперь тестируются только на поддерживаемых версиях. Не обновляться нельзя, обновляться на 5.7 — лотерея.
- Модули Маркетплейса. Разработчики модулей ориентируются на политику Битрикса. Новые версии CRM-коннекторов, платёжных модулей и обмена с 1С будут собираться под MySQL 8.
- Хостинг. Провайдеры сворачивают тарифы со старыми СУБД. Однажды вы получите письмо «мы обновили MySQL» — без тестового прогона вашего сайта.
Как проверить, на чём вы сейчас
Четыре способа, от простого к техническому:
- Админка Битрикса: Настройки → Инструменты → Проверка системы. Там же видно версию PHP и предупреждения о кодировках.
- SQL-запрос SELECT VERSION() в любом клиенте базы.
- По SSH на сервере: mysql -V.
- Панель хостинга — раздел «Базы данных» или «Версии ПО».
Если видите 5.7 или 5.6 — читайте дальше. Если 8.0 — вы в порядке на сегодня, но 8.0 уже без поддержки Oracle, так что 8.4 всё равно в планах.
Что ломается при переезде на MySQL 8
Восьмёрка — не «та же база, только новее». У неё другие умолчания, и именно они создают проблемы.
| Изменение в MySQL 8 | Как проявляется на сайте |
|---|---|
| Кодировка по умолчанию utf8mb4 и новые collation | Ошибки вида Illegal mix of collations при JOIN старых и новых таблиц |
| Плагин аутентификации caching_sha2_password | Старые клиенты и интеграции теряют доступ к базе |
| Удалён query cache | Сервер не стартует, если в my.cnf остались директивы query_cache_* |
| Новые зарезервированные слова: RANK, GROUPS, ROWS | Падают самописные запросы, где эти слова не в кавычках |
| GROUP BY больше не сортирует неявно | Порядок строк меняется там, где не было явного ORDER BY |
| Строгий sql_mode по умолчанию | Нулевые даты 0000-00-00 и обрезание строк становятся ошибками |
Самая частая история — кодировки. Проверка системы Битрикса начинает писать «Кодировки таблиц имеют ошибки»: база в utf8mb3, а ядро ждёт utf8mb4. Лечится в три шага: перевести базу (ALTER DATABASE … CHARACTER SET utf8mb4), поправить SET NAMES и collation в файлах after_connect.php и after_connect_d7.php, а затем конвертировать таблицы (ALTER TABLE … CONVERT TO CHARACTER SET utf8mb4). После этого — оптимизация базы через штатные инструменты админки.
План переезда по шагам
Это мой рабочий порядок. Он длиннее, чем «сделать дамп и залить», зато ни разу не заканчивался откатом в панике.
- Полный бэкап вне сервера. Дамп базы плюс копия файлов — и хранить не на том же VPS.
- Аудит проекта. Размер базы, список кастомных модулей, места с прямыми SQL-запросами, содержимое my.cnf.
- Тестовое окружение с MySQL 8.4. Отдельный сервер или контейнер, куда заливается дамп. Все ошибки импорта — в список.
- Утилита checkForServerUpgrade из MySQL Shell. Она находит несовместимости до того, как их найдут пользователи.
- Прогон ключевых сценариев. Каталог, фильтры, корзина, оформление заказа, поиск, обмен с 1С, выгрузки в маркетплейсы.
- Исправления. Кодировки, запросы, чистка конфига от query_cache, замена плагина аутентификации для интеграций.
- Переключение в окно обслуживания с готовым сценарием отката.
- Неделя наблюдения за логами. Ошибки MySQL и PHP смотреть ежедневно.
Если сайт на виртуальном хостинге, шаги 3–7 часто делает провайдер бесплатно по заявке. На VPS небольшой сайт занимает у администратора около рабочего дня. У подрядчиков в 2026-м это оценивается в 8–20 часов работы, то есть примерно 35–90 тысяч рублей в зависимости от объёма кастома — ориентир по рынку.
PHP 8.4 — в ту же поездку
Раз уж вы делаете окно обслуживания, закройте и вопрос PHP. Здесь одно железное правило Битрикса: версии поднимать постепенно. Не с 7.4 сразу на 8.4, а 7.4 → 8.0 → 8.1 → 8.2 → 8.4, после каждого шага — обновление ядра и модулей через Настройки → Маркетплейс. Прыжок через версии почти всегда заканчивается фатальными ошибками в сторонних модулях.
Порядок такой: сначала обновить ядро и все модули на текущей версии PHP, потом поднимать PHP по одной ступени, после каждой — снова проверять обновления. Да, это долго. Но альтернатива — разбирать белый экран на проде.
Чек-лист на одну страницу
- Версия MySQL проверена; если ниже 8.0 — переезд запланирован на конкретную дату.
- Версия PHP проверена; если ниже 8.2 — составлена лестница обновления.
- Бэкап сделан и лежит вне сервера, восстановление проверено.
- Есть тестовое окружение с MySQL 8.4 и результатами checkForServerUpgrade.
- Кастомные модули и прямые SQL-запросы проверены на зарезервированные слова и GROUP BY.
- Из my.cnf убраны директивы query_cache_*.
- Интеграции (1С, CRM, платёжки) проверены на новый плагин аутентификации.
- После переезда Проверка системы в админке зелёная, кодировки — utf8mb4.
Пара слов напоследок
Переезд на MySQL 8 — не про «сделать красиво». Это страховка от ситуации, когда обновление безопасности ломает сайт, а откатиться некуда. Если ваш Битрикс всё ещё на 5.7, самое разумное — сделать это в спокойном режиме в ближайший месяц, а не после первого сбоя. Как это устроено у меня в поддержке и разработке на Битриксе — на странице корпоративных сайтов на Битрикс. Заодно почитайте, как ускорить Битрикс: после переезда на MySQL 8.4 с правильным innodb_buffer_pool_size база обычно заметно быстрее.
