Битрикс прекращает поддержку старых MySQL: план перехода до 1 сентября

В админках сайтов на «1С-Битрикс: Управление сайтом» с зимы висит уведомление: с 1 сентября 2026 года поддержка продуктов на MySQL ниже 8.0.0 будет ограничена, рекомендуемая версия — 8.4 и выше. Сайт в этот день не выключится, но ядро на старой базе будет обновляться уже без гарантий совместимости. Показываю, как за две минуты проверить версию MySQL, что реально ломается при переезде на восьмую ветку и как провести миграцию без простоя — по шагам, в том порядке, в котором мы делаем это на проектах поддержки.

Что объявил Битрикс

Уведомление появляется в административной панели при установке обновлений с февраля 2026 года: «С 01.09.2026 будет ограничена поддержка наших продуктов на MySQL версии ниже 8.0.0. Рекомендуемая версия MySQL — 8.4.0 и выше. Пожалуйста, запланируйте обновление MySQL или обратитесь в службу технической поддержки вашего хостинга». Требование касается всех продуктов на платформе Bitrix Framework, включая коробочный Битрикс24; актуальный список окружений вендор ведёт на странице системных требований.

Это второй шаг зачистки старых окружений за год. С 1 февраля 2026 года Битрикс прекратил поддержку PHP ниже 8.2, и тогда тоже было заметно, как долго тянули с обновлением те, кого предупреждали за полгода. Теперь очередь базы данных.

Слово «ограничена» стоит понимать буквально. Первого сентября сайт на MySQL 5.7 не выключится и даже не покажет ошибку. Но новые версии ядра и модулей будут тестироваться только на MySQL 8.0+, техподдержка вендора вправе отказать в разборе проблем на старой базе, а очередное обновление в любой момент может начать использовать синтаксис, которого в пятой ветке нет. Работать «как раньше» сайт будет ровно до первого такого обновления.

Как узнать, касается ли это вашего сайта

Проверка занимает пару минут, доступ к серверу не обязателен.

1. В админке откройте «Настройки → Инструменты → Проверка системы». В отчёте о конфигурации указана версия MySQL (или MariaDB — о ней ниже).
2. Второй способ там же: «Настройки → Инструменты → Командная SQL-строка», запрос SELECT VERSION();.
3. Если есть SSH-доступ: mysql -V на сервере или тот же запрос в консольном клиенте.
4. На виртуальном хостинге версия обычно видна в панели управления, там же часто есть переключатель версий MySQL.

Если в ответе цифра 8.0 и выше — эта статья для вас справочная. Если 5.6 или 5.7 — пора планировать переезд. В зоне риска в первую очередь сайты на VPS, развёрнутые до 2023 года на окружении BitrixVM 7.x: туда MySQL 5.7 ставился по умолчанию, и без ручного вмешательства он там и остался. Виртуальные хостинги в массе давно перешли на восьмую ветку.

Отдельный случай — MariaDB. Формально Битрикс работает и на ней, но требования вендор формулирует именно в версиях MySQL, и часть возможностей восьмой ветки в MariaDB реализована иначе. Если у вас MariaDB 10.3 и старше, обсудите с хостингом обновление минимум до 10.6, а при переносе на новый сервер разумнее сразу ставить MySQL 8.4.

Что будет, если остаться на старом MySQL

Короткий ответ: какое-то время ничего, потом дорого.

Oracle прекратила поддержку MySQL 5.7 ещё 31 октября 2023 года (график жизненного цикла есть на endoflife.date). Почти три года эта версия не получает даже патчей безопасности. База данных, в которой лежат заказы, пользователи и пароли, работает на неподдерживаемом софте — сама по себе плохая новость, независимо от требований Битрикса. Про то, чем заканчивается экономия на обновлениях, мы писали в разборе уязвимостей 1С-Битрикс.

Дальше сработает эффект домино. Хостинги выводят старые версии из эксплуатации и рано или поздно поставят перед фактом принудительного апгрейда — в неудобный момент и без тестового прогона. Обновления ядра, которые нельзя ставить, начнут копиться, а запущенные обновления Битрикса превращают простую задачу в проект: чем дольше тянуть, тем шире разрыв между вашей конфигурацией и той, на которой вендор всё тестирует.

Моё мнение: откладывать миграцию на конец августа — худший из вариантов. В последние недели перед дедлайном у хостингов и студий поддержки образуется очередь из таких же отложивших, и спокойный переезд со стендом превращается в ночной аврал. Август для этой задачи и так последний месяц, а не запас.

Что может сломаться при переходе на MySQL 8

Типовое ядро Битрикса с восьмой веткой совместимо давно, у свежих установок проблем нет. Ломается обычно не ядро, а наследство конкретного проекта: кастомные модули, самописные запросы, старые настройки сервера. Основные точки риска собрал в таблицу.

Главный вывод из таблицы: заранее предсказать, зацепит ли вас хоть один пункт, нельзя — это выясняется только прогоном копии сайта на тестовой базе. Именно поэтому миграция «переключим версию в панели и посмотрим» на живом магазине — плохая идея.

План миграции: 8 шагов

Схема, по которой мы в Design Lab переводим проекты поддержки на MySQL 8. Она консервативная: апгрейд на месте, поверх работающей базы, я не делаю никогда — только параллельный сервер с переключением, чтобы в любой момент можно было откатиться.

1. Полный бэкап: дамп базы через mysqldump плюс копия файлов сайта. Бэкап хранится вне сервера, на котором идут работы.
2. Аудит проекта: версия и объём базы, список кастомных модулей, поиск прямых SQL-запросов в local/ и bitrix/php_interface/. Смотрим и конфиг my.cnf — что из него переживёт переезд.
3. Тестовый стенд с MySQL 8.0 или 8.4: заливаем дамп и внимательно читаем ошибки импорта — кодировки и нулевые даты всплывают уже на этом шаге.
4. Проверка утилитой checkForServerUpgrade из MySQL Shell: она находит несовместимости до переноса, включая зарезервированные слова. Официальное руководство по апгрейду — в документации MySQL. Прямой переход поддерживается с 5.7; если у вас 5.6, сначала промежуточный шаг на 5.7.
5. Прогон сайта на стенде: «Проверка системы» в админке, ключевые сценарии руками — каталог, корзина, оформление заказа, поиск, обмен с 1С, письма. Параллельно смотрим логи ошибок.
6. Фикс найденного: приведение кодировок, правка запросов, чистка my.cnf, при необходимости mysql_native_password для старых интеграций как временная мера.
7. Переключение прода в технологическое окно: финальный дамп, перенос, переключение сайта на новую базу, час наблюдения за логами. Старая база остаётся нетронутой как точка отката.
8. Контроль в первую неделю: медленные запросы, планы выполнения, подгонка innodb_buffer_pool_size под память сервера. Обычно после переезда база работает не медленнее, а на тяжёлых выборках быстрее.

На небольшом корпоративном сайте всё это укладывается в один рабочий день плюс окно на переключение. Магазин с обменом 1С и кастомными модулями — история на несколько дней, в основном из-за тестирования.

Сроки, стоимость и кому это поручить

Если сайт на виртуальном хостинге, начните с письма в поддержку хостера: часто достаточно переключить версию MySQL в панели, предварительно проверив копию сайта на тестовом домене. Это бесплатно.

На VPS с root-доступом задача решается своими руками, если в команде есть администратор: свежее окружение BitrixVM 9 уже идёт с MySQL 8.4, и разумный путь — развернуть новый сервер и перенести сайт на него, а не обновлять базу на старом. Заодно обновится и остальной стек.

Если отдавать подрядчику: по открытым прайсам студий поддержки в 2026 году миграция на MySQL 8 оценивается от 8 до 20 часов работы специалиста в зависимости от размера проекта, в деньгах — примерно от 35 до 90 тыс. руб. Для клиентов на абонементе поддержки сайта на Битрикс такие работы обычно закрываются в рамках пакета часов, отдельного бюджета не требуется.

Что сделать до конца августа

Минимальный план на ближайшую неделю: проверить версию MySQL любым способом из второго раздела; если она ниже 8.0 — сделать полный бэкап и назначить дату миграции, не дожидаясь последней недели августа; если проект на поддержке у подрядчика — просто поставить ему задачу и спросить про тестовый стенд. В Design Lab мы к сентябрьскому дедлайну проверяем версии базы на всех проектах поддержки штатно, в рамках регламента.

А если не уверены, что на вашем сайте вообще творится с окружением — начните с аудита, версия MySQL там один из первых пунктов чек-листа.