Битрикс на MySQL 8.4: my.cnf, mysql_native_password и проверка базы

С февраля 2026 года в админке Битрикса висит уведомление: с 01.09.2026 поддержка продуктов на MySQL ниже 8.0.0 ограничена, рекомендована версия 8.4.0 и выше. У самой MySQL 8.0 поддержка закончилась 30 апреля 2026 года, так что сайтам, которые уже переехали на восьмую ветку, предстоит ещё один шаг. Я прогнал этот шаг на стенде: MySQL 8.0.46 с базой, похожей на старую установку Битрикса, затем MySQL 8.4.11 поверх того же каталога данных. Ниже то, что сломалось, точные тексты ошибок и проверки, которые стоит сделать до перезапуска сервера.

Короткий ответ:

• my.cnf. MySQL 8.4 не стартует, если в конфиге остались expire_logs_days, default_authentication_plugin или skip-host-cache. Строки query_cache_*, innodb_large_prefix и innodb_file_format ломают запуск ещё с 8.0. Проверьте конфиг заранее командой mysqld --validate-config от новой версии.
• Пользователь сайта. Если его создали с плагином mysql_native_password, после обновления сайт получит Plugin 'mysql_native_password' is not loaded. Переведите пользователя на caching_sha2_password или временно включите старый плагин строкой mysql_native_password=ON.
• Схема. Столбец FLOAT или DOUBLE с AUTO_INCREMENT останавливает обновление целиком. Столбцы с именами qualify, manual, parallel и tablesample в запросах без обратных кавычек дают синтаксическую ошибку.
• Кодировки. Для MySQL 8.x Битрикс рекомендует utf8mb4 с сортировкой utf8mb4_0900_ai_ci. Таблицы с utf8mb4_unicode_ci рядом с новыми дают Illegal mix of collations.

Рядом по теме: медленный MySQL на BitrixVM, где искать активный my.cnf и max_allowed_packet, перевод базы в utf8mb4 ради emoji, перенос Битрикса на новый хостинг.

Если переход нужно провести на живом проекте и без долгого простоя — с этим можно прийти на karoche.ru.

Что требует Битрикс и почему именно 8.4

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

Источник	Что сказано
Требования к серверному ПО в документации Битрикса (изменены 16.01.2026)	MySQL 8.0 и выше; utf8mb4 вместо utf8mb3; для MySQL 8.x и 9.x сортировка utf8mb4_0900_ai_ci, для MariaDB utf8mb4_unicode_ci
Уведомление в админке (с февраля 2026)	с 01.09.2026 поддержка на MySQL ниже 8.0.0 ограничена, рекомендована 8.4.0 и выше
endoflife.date	у MySQL 8.0 конец поддержки 30.04.2026, у 8.4 LTS активная поддержка до 30.04.2029
Документация BitrixVM (страница изменена 10.02.2026)	с версии 9.0.6 MySQL обновляется до 8.4 через меню; PHP, MySQL и PostgreSQL сами не обновляются

Для РЕД ОС, ALT, Astra и похожих систем Битрикс советует MariaDB. Всё, что ниже, относится к MySQL: у MariaDB свои версии и свой набор отличий.

Какой путь обновления выбрать

С 8.0 на 8.4 документация MySQL поддерживает три пути: обновление на месте, перенос через дамп и загрузку, переход через реплику. С 5.7 сразу на 8.4 перейти нельзя: сначала 5.7 обновляют до 8.0, потом 8.0 до 8.4.

На BitrixVM начиная с 9.0.6 обновление идёт из меню: 1. Manage servers in the pool, затем 6. Update PHP, MySQL, PostgreSQL. Логи этой операции лежат в /opt/webdir/temp. На своём сервере с пакетами из репозитория MySQL это обычное обновление пакетов.

Перед любым вариантом нужны две копии:

1. Дамп базы через mysqldump.
2. Копия каталога данных при остановленном сервере.

На стенде именно копия каталога позволила за минуту вернуться на 8.0, когда первый запуск 8.4 упал. Если сервер обычно работает с innodb_fast_shutdown = 2, документация просит перед остановкой выставить 1 или 0. Я останавливал 8.0 с SET GLOBAL innodb_fast_shutdown=0.

Утилиты mysql_upgrade в 8.4 больше нет. Сервер сам обновляет словарь данных и системные таблицы при первом запуске на старом каталоге. В журнале ошибок это выглядит так:

[System] [MY-011090] [Server] Data dictionary upgrading from version '80023' to '80300'.
[System] [MY-013413] [Server] Data dictionary upgrade from version '80023' to '80300' completed.
[System] [MY-013381] [Server] Server upgrade from '80046' to '80411' started.
[System] [MY-013381] [Server] Server upgrade from '80046' to '80411' completed.

Как проверить my.cnf до перезапуска

У mysqld есть ключ --validate-config. Он читает конфигурацию, не запуская сервер в обычном режиме, и выходит с кодом 0, если ошибок нет, или с кодом 1 на первой ошибке. Чтобы проверить текущий конфиг новой версией, сервер обновлять не нужно. Достаточно распаковать архив MySQL 8.4 в домашний каталог, root для этого не нужен:

cd ~
curl -O https://cdn.mysql.com/Downloads/MySQL-8.4/mysql-8.4.11-linux-glibc2.28-x86_64-minimal.tar.xz
tar xf mysql-8.4.11-linux-glibc2.28-x86_64-minimal.tar.xz
cd mysql-8.4.11-linux-glibc2.28-x86_64-minimal
./bin/mysqld --defaults-file=/etc/my.cnf --basedir="$PWD" --validate-config
echo "exit: $?"

Несколько деталей:

• --defaults-file должен идти первым ключом, иначе mysqld его не распознает.
• Подключаемые каталоги из !includedir тоже читаются. На стенде устаревшая строка в подключаемом файле дала ту же ошибку, что и в основном конфиге.
• Путь к конфигу зависит от сборки, часто это /etc/my.cnf или /etc/mysql/my.cnf. Порядок чтения файлов покажет ./bin/mysqld --verbose --help | grep -A1 'Default options'.
• Бинарнику нужна библиотека libaio.so.1. В Debian 13 пакет называется libaio1t64 и даёт файл libaio.so.1t64. Я положил симлинк libaio.so.1 в отдельный каталог и указал его в LD_LIBRARY_PATH.
• Версия в ссылке актуальна на 6 октября 2026 года, новую сборку берите с той же страницы загрузок.

Для конфига со старой строкой вывод выглядит так:

[ERROR] [MY-000067] [Server] unknown variable 'expire_logs_days=7'.
[ERROR] [MY-010119] [Server] Aborting

Я прогнал типовые строки из старых конфигов через обе версии:

Строка в my.cnf	8.0.46	8.4.11	Чем заменить
query_cache_size, query_cache_type	не стартует	не стартует	удалить
innodb_large_prefix, innodb_file_format	не стартует	не стартует	удалить
expire_logs_days=7	стартует	не стартует	binlog_expire_logs_seconds=604800
default_authentication_plugin=mysql_native_password	стартует	не стартует	удалить, политика задаётся через authentication_policy
skip-host-cache	стартует	не стартует	host_cache_size=0
transaction-isolation=READ-COMMITTED, innodb_strict_mode=OFF, sql_mode=	стартует	стартует	оставить

Полный список удалённых параметров есть в разделе документации о том, что нового в 8.4. Ключ проверяет только параметры, которые сервер может разобрать без запуска движков и плагинов, так что после него всё равно нужен пробный старт.

Если my.cnf за годы оброс советами разных поколений и разбирать его некогда — разбор конфигурации можно заказать через karoche.ru.

Что делать с ошибкой Plugin ‘mysql_native_password’ is not loaded

В 8.4 плагин mysql_native_password по-прежнему есть, но по умолчанию выключен. Учётные записи после обновления сохраняют свой плагин, поэтому пользователь сайта, созданный когда-то с mysql_native_password, перестаёт подключаться. На стенде консольный клиент и PHP 8.4 через mysqli получили одну и ту же ошибку:

ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded
mysqli (127.0.0.1): [1524] Plugin 'mysql_native_password' is not loaded
mysqli (socket): [1524] Plugin 'mysql_native_password' is not loaded

Проверить заранее можно ещё на 8.0:

SELECT user, host, plugin
FROM mysql.user
WHERE plugin = 'mysql_native_password';

Логин пользователя сайта лежит в /bitrix/.settings.php, в секции connections. До версии главного модуля 20.900.0 параметры подключения хранились в /bitrix/php_interface/dbconn.php.

На время перехода можно включить старый плагин в секции [mysqld]:

[mysqld]
mysql_native_password=ON

С этой строкой вход снова работает, а в журнале появляется предупреждение:

[Warning] [MY-013360] [Server] Plugin mysql_native_password reported: ''mysql_native_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead'

Постоянное решение — сменить плагин у пользователя. Пароль при этом задаётся заново, можно оставить прежний из .settings.php:

ALTER USER 'bitrix'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'пароль_из_settings';
ALTER USER 'bitrix'@'127.0.0.1' IDENTIFIED WITH caching_sha2_password BY 'пароль_из_settings';

После этого PHP 8.4.26 через mysqli подключился и через сокет, и по TCP на 127.0.0.1 без TLS. caching_sha2_password работает и в 8.0, поэтому пользователя удобнее перевести до обновления. Тогда в день перехода на этом шаге ничего не упадёт.

Что проверить в схеме до обновления

Первый запуск 8.4 на стенде упал из-за одной тестовой таблицы со столбцом FLOAT и AUTO_INCREMENT. В 8.0 такая таблица создаётся с предупреждением 3856. В 8.4 сервер с такой таблицей не поднимается:

[ERROR] [MY-015118] [Server] AUTO_INCREMENT is not supported with DOUBLE/FLOAT field. Please consider fixing (Schema:bx, Table:t_float, Column:ID).
[ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
[ERROR] [MY-010119] [Server] Aborting

Я вернул копию каталога, запустил 8.0, сменил тип столбца на INT, и второй запуск 8.4 прошёл. Найти такие столбцы заранее:

SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, DATA_TYPE
FROM information_schema.COLUMNS
WHERE EXTRA LIKE '%auto_increment%'
  AND DATA_TYPE IN ('float', 'double')
  AND TABLE_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');

В 8.4 появились новые зарезервированные слова: MANUAL, PARALLEL, QUALIFY и TABLESAMPLE. Таблица со столбцами qualify и manual переживает обновление, но запрос без кавычек падает:

ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'qualify, manual FROM b_custom_words' at line 1

С обратными кавычками тот же SELECT отработал. Поиск по схеме:

SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
FROM information_schema.COLUMNS
WHERE UPPER(COLUMN_NAME) IN ('MANUAL', 'PARALLEL', 'QUALIFY', 'TABLESAMPLE')
  AND TABLE_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');

Если запрос что-то нашёл, ищите эти имена в своём коде в local/ и bitrix/php_interface/: рискуют прямые SQL-запросы, где имя столбца написано без кавычек. Для более широкой проверки у MySQL есть Upgrade Checker в MySQL Shell. На этом стенде я его не запускал.

Нужны ли SET sql_mode и innodb_strict_mode в after_connect_d7.php

Значения по умолчанию на чистой 8.4.11 я снял запросом от пользователя сайта:

@@GLOBAL.sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
@@SESSION.innodb_strict_mode: 1
@@transaction_isolation: REPEATABLE-READ

При строгом sql_mode слишком длинная строка не записывается:

ERROR 1406 (22001) at line 1: Data too long for column 'NAME' at row 1

После SET SESSION sql_mode='' тот же INSERT проходит с предупреждением 1265, и в столбце остаётся обрезанное значение Слишком дл. Старый код, который годами молча терял хвосты строк, в строгом режиме начинает падать.

В блогах для таких случаев советуют добавить в /bitrix/php_interface/after_connect_d7.php строки SET sql_mode='' и SET innodb_strict_mode=0. На форуме Битрикса есть обратная история: после перехода хостинга с MySQL 5 на 8 сайт ломался, и помогало удаление строки с innodb_strict_mode. Я проверил обе команды на стенде. Первая выполнилась у обычного пользователя. Вторая упала и на 8.0.46, и на 8.4.11 у пользователя с ALL на свою базу:

SET sql_mode='' -> ok
SET innodb_strict_mode=0 -> [1227] Access denied; you need (at least one of) the SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation

В той же ветке форума пишут, что в MySQL 8 параметр по умолчанию уже равен 0. На стенде с настройками по умолчанию обе версии вернули 1, на хостинге значение может быть задано в конфиге сервера. Проверка: SHOW VARIABLES LIKE 'innodb_strict_mode'.

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

• задать innodb_strict_mode=OFF в [mysqld], после рестарта на стенде и глобальное, и сессионное значение стали 0;
• выдать пользователю сайта SESSION_VARIABLES_ADMIN, после GRANT SESSION_VARIABLES_ADMIN ON *.* TO 'bitrix'@'localhost' та же команда SET выполнилась.

Обе настройки ослабляют проверки, поэтому включайте их под конкретную ошибку, без запаса на всякий случай.

Какую сортировку выбрать: utf8mb3, utf8mb4_unicode_ci или utf8mb4_0900_ai_ci

Новая база без явной кодировки на 8.4 получает utf8mb4 и utf8mb4_0900_ai_ci. Старая база Битрикса часто остаётся в utf8mb3. На стенде вышло так:

Сочетание	Результат
emoji в столбец utf8mb3	ERROR 1366 Incorrect string value: '\xF0\x9F\x91\x8D'
JOIN utf8mb3_unicode_ci = utf8mb4_0900_ai_ci	работает
JOIN utf8mb4_unicode_ci = utf8mb4_0900_ai_ci	ERROR 1267 Illegal mix of collations

Самая неприятная пара — две разные сортировки utf8mb4. Такое случается, когда часть таблиц когда-то перевели в utf8mb4_unicode_ci, а новые создаются уже с сортировкой сервера. Таблицы в базе сайта, которые выбиваются из рекомендации Битрикса:

SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_COLLATION <> 'utf8mb4_0900_ai_ci';

Команда для одной таблицы, после неё emoji на стенде сохранился:

ALTER TABLE b_old CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

Порядок для всей базы с дампом и правкой подключения описан в заметке про emoji в Битриксе. Для MySQL 8.x в ней стоит взять utf8mb4_0900_ai_ci вместо utf8mb4_unicode_ci, а строки innodb_large_prefix и innodb_file_format пропустить: этих параметров нет с 8.0, и сервер с ними не стартует. На больших таблицах такой ALTER идёт долго, их лучше переводить в окно работ.

Что ещё меняется после перехода на 8.4

• Удалены старые команды репликации. SHOW SLAVE STATUS теперь даёт синтаксическую ошибку, вместо этой команды — SHOW REPLICA STATUS. Это касается скриптов мониторинга.
• FLUSH HOSTS тоже удалена. Кэш хостов очищается через TRUNCATE TABLE performance_schema.host_cache или mysqladmin flush-hosts.
• Поменялись значения InnoDB по умолчанию, например innodb_adaptive_hash_index теперь OFF, innodb_io_capacity 10000, innodb_change_buffering none. Явно заданные в my.cnf значения остаются, остальные меняются вместе с версией. После перехода сравните медленные запросы с тем, что было до него.

Как я проверял

Стенд собран на Debian 13 без Docker и без root:

• официальные архивы MySQL 8.0.46 и 8.4.11 (minimal) распакованы в отдельный каталог;
• сервер запущен с временным каталогом данных, отдельным сокетом и портом;
• на 8.0 созданы база в utf8mb3_unicode_ci, пользователь bitrix с mysql_native_password, таблица со столбцами qualify и manual, таблица с FLOAT AUTO_INCREMENT;
• затем 8.0 остановлен медленным выключением, каталог скопирован, 8.4 запущен на том же каталоге;
• подключение проверялось консольным клиентом 8.4 и PHP 8.4.26 через mysqli.

Самого Битрикса на стенде не было. База имитирует старую установку, поведение ядра Битрикса на 8.4 этот тест не проверяет. Поэтому после обновления нужна ещё и проверка самого сайта.

В каком порядке переходить

1. Дамп базы и копия каталога данных при остановленном сервере.
2. mysqld --validate-config новой версии на текущем my.cnf, правка строк из таблицы выше.
3. Три запроса к схеме: пользователи с mysql_native_password, FLOAT и DOUBLE с AUTO_INCREMENT, новые зарезервированные слова.
4. Перевод пользователя сайта на caching_sha2_password, пока сервер ещё на 8.0.
5. Ревизия after_connect_d7.php: убрать SET innodb_strict_mode, если у пользователя нет нужной привилегии.
6. Обновление через меню BitrixVM или пакеты, затем проверка строки Server upgrade from ... completed в журнале ошибок.
7. Проверка системы в админке и ручной проход по ключевым сценариям сайта: каталог, корзина, формы, обмен.

Что делать, если совет не подходит

• Виртуальный хостинг. К my.cnf и mysql.user доступа обычно нет. Спросите у поддержки, какую версию MySQL и какой плагин входа получит ваш пользователь, и проверьте сайт на тестовой копии до переключения.
• MariaDB. Ошибки из этой статьи относятся к MySQL. Для MariaDB Битрикс рекомендует сортировку utf8mb4_unicode_ci, и сверяться стоит с документацией MariaDB.
• Сервер на 5.7. Сначала переход на 8.0 с теми же проверками, потом на 8.4. Строки query_cache_* и innodb_large_prefix придётся убрать уже на первом шаге.
• Откат. Надёжный откат — копия каталога данных или дамп, сделанные до первого запуска 8.4. На стенде возврат к копии сработал. Без копии этот путь закрыт.

Как проверить, что всё прошло

SELECT VERSION();
SELECT user, host, plugin FROM mysql.user WHERE user NOT LIKE 'mysql.%';
SHOW PLUGINS;

Ожидаемый результат: версия 8.4.x, у пользователя сайта caching_sha2_password, в журнале ошибок есть Server upgrade ... completed и нет строк [ERROR] после запуска. Сайт открывается, в проверке системы нет новых замечаний по базе.

Типичные ошибки

Симптом	Причина	Что сделать
unknown variable 'expire_logs_days=7', сервер не стартует	параметр удалён в 8.4	binlog_expire_logs_seconds
unknown variable 'query_cache_size=0'	query cache удалён ещё в 8.0	удалить строки query_cache_*
ERROR 1524 Plugin 'mysql_native_password' is not loaded	пользователь на старом плагине	ALTER USER ... caching_sha2_password или mysql_native_password=ON
MY-015118 AUTO_INCREMENT is not supported with DOUBLE/FLOAT field	столбец FLOAT или DOUBLE с AUTO_INCREMENT	на 8.0 сменить тип на INT или BIGINT
ERROR 1064 ... near 'qualify	новое зарезервированное слово	обратные кавычки вокруг имени
ERROR 1227 ... SESSION_VARIABLES_ADMIN	SET innodb_strict_mode в after_connect_d7.php	убрать строку или задать параметр в my.cnf
ERROR 1267 Illegal mix of collations	две разные сортировки utf8mb4	привести таблицы к utf8mb4_0900_ai_ci
ERROR 1366 Incorrect string value	четырёхбайтовый символ в utf8mb3	CONVERT TO CHARACTER SET utf8mb4
ERROR 1064 ... near 'SLAVE STATUS'	старая команда репликации	SHOW REPLICA STATUS

Источники

• Требования к серверному программному обеспечению, документация Битрикса
• BitrixVM: обновление PHP, MySQL, PostgreSQL
• Ошибки подключения к БД, документация Битрикса
• Текст уведомления о поддержке MySQL ниже 8.0.0
• Что нового в MySQL 8.4 по сравнению с 8.0
• Пути обновления MySQL 8.4
• Обновление бинарной или пакетной установки
• Проверка конфигурации сервера
• Привилегии для системных переменных
• Сроки поддержки версий MySQL

Практические заметки и услуги вокруг Битрикса и веб-разработки — на karoche.ru.