Обновление PHP и MySQL для 1С-Битрикс: как перейти на актуальное окружение без аварии

Сайт на 1С-Битрикс может годами работать на старом сервере, пока хостинг не объявит об отключении прежней версии PHP или база данных не перестанет соответствовать требованиям продукта. В этот момент обычный переключатель версии кажется быстрым решением. На практике он одновременно затрагивает ядро, сторонние модули, собственный код, фоновые задания, обмены и хранение данных.

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

Почему старое окружение нельзя оставлять как есть

С 1 февраля 2026 года в официальных требованиях 1С-Битрикс указана минимальная версия PHP 8.2, а рекомендуемая — 8.4 и выше. Для MySQL требуется версия 8.0 и выше, база и серверные компоненты должны работать в UTF-8. Это не означает, что любой старый проект автоматически готов к новым версиям: требования описывают платформу, но не проверяют код конкретного сайта.

Отдельная причина не откладывать работы — жизненный цикл самих технологий. Согласно release notes MySQL 8.0, эта ветка достигла конца жизненного цикла в апреле 2026 года, и разработчик СУБД рекомендует переходить на MySQL 8.4 LTS или более новую поддерживаемую ветку. У PHP тоже есть ограниченные сроки активной и security-поддержки. Поэтому перенос со старого PHP на первую формально допустимую версию может дать только короткую передышку.

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

Какие части проекта меняются одновременно

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

• Код проекта. Ядро Битрикса, решения Marketplace, локальные модули, шаблоны компонентов и обработчики событий должны корректно выполняться на новой версии PHP.
• PHP-окружение. Веб-сервер, PHP-FPM, консольный PHP, OPcache, настройки php.ini и набор расширений должны соответствовать друг другу.
• База данных. Важны не только номер MySQL, но и движки таблиц, кодировки, сортировки, SQL-режимы, пользователи и права подключения.
• Фоновые процессы. Cron, агенты, резервное копирование, импорт каталога, обмен с 1С и очереди часто используют отдельный путь к PHP и не проверяются обычным открытием страницы.

Полезно сразу отделить эту задачу от обновления ядра и модулей 1С-Битрикс. Эти работы связаны, но у них разные точки риска. Если одновременно заменить окружение, обновить ядро и переписать компонент, по первой ошибке будет трудно определить причину.

Что собрать до первого переключения

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

Минимальный набор исходных данных:

• версия главного модуля Битрикса и всех установленных модулей;
• версии PHP в вебе и командной строке, путь к исполняемому файлу в cron;
• список PHP-расширений: mysqli, mbstring, curl, openssl, gd, zip, xml и проектные зависимости;
• тип и версия СУБД, размеры базы и крупнейших таблиц, свободное место на диске;
• кодировки и сортировки базы, таблиц и текстовых колонок;
• расписание cron, агенты и отдельные скрипты импорта, экспорта и резервирования;
• активные интеграции: 1С, CRM, SMTP, оплата, доставка и внешние API;
• свежие PHP-, веб-серверные и системные логи без маскировки предупреждений.

Особое внимание стоит уделить несовпадению веб- и CLI-версий. Страница может уже выполняться на PHP 8.4, а ночной обмен продолжать запускаться через системный /usr/bin/php старой версии. Возможна и обратная ситуация: cron первым получает новую версию и перестаёт выполнять задания, хотя публичный сайт выглядит исправным.

Если состав проекта неизвестен, перед миграцией разумно провести технический аудит сайта на 1С-Битрикс. Он помогает отделить обязательные исправления совместимости от улучшений, которые можно выполнить позже и не смешивать с переключением.

Почему тестовая копия важнее сообщения «бэкап создан»

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

На копии сначала фиксируют базовое состояние: главная и типовые страницы открываются, можно войти в административную часть, создать тестовый элемент, оформить заказ, запустить нужный обмен. Только после этого меняют одну часть окружения. Иначе неизвестно, возникла ошибка из-за обновления или уже присутствовала в копии.

Резерв должен включать не только данные сайта:

• полную копию файлов и загрузок;
• логический дамп базы с проверкой завершения и размера;
• конфигурацию PHP-FPM, веб-сервера, cron и переменные окружения;
• список пакетов и расширений, которые нужно восстановить на старом контуре;
• понятную инструкцию, кто и за какое время выполняет возврат.

Подробно этот принцип разобран в материале о проверке резервной копии 1С-Битрикс восстановлением. Для магазина дополнительно нужно определить, что произойдёт с заказами, появившимися после финального дампа. Обычно на время последней синхронизации ограничивают операции записи, а не надеются затем вручную собрать расхождения.

Как отдельно проверить переход на новую версию PHP

PHP лучше переключать на тестовой копии до изменения СУБД. Так ошибки языка и расширений не смешиваются с изменениями базы. Если переход выполняется через несколько веток, для каждой читают официальные migration guides. Например, руководство по переходу на PHP 8.4 отдельно перечисляет несовместимые и устаревшие возможности, которые нужно проверить до production.

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

Практический чек-лист PHP:

1. обновить ядро и сторонние модули до версий, совместимых с целевой веткой PHP;
2. проверить собственный код статическим анализом и реальными сценариями;
3. сравнить набор расширений и критичные параметры php.ini;
4. проверить веб, CLI и каждый путь к PHP в cron;
5. после переключения сбросить OPcache и убедиться, что процессы используют новую конфигурацию;
6. просмотреть журнал ошибок после полного сценарного прохода.

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

Что проверить при обновлении MySQL

У базы данных свой маршрут обновления. Официальная документация MySQL не допускает произвольного пропуска основных веток: для перехода с MySQL 5.7 на 8.4 используется промежуточный этап 8.0, затем переход на 8.4 LTS. Перед обновлением MySQL рекомендует запускать Upgrade Checker, устранять найденные несовместимости и повторять процедуру на тестовой установке.

Для сайта на Битриксе отдельно проверяются:

• устаревшие типы, значения дат, зарезервированные слова и запросы собственного кода;
• различия в sql_mode, которые превращают прежнее предупреждение в ошибку;
• движки таблиц, индексы и время импорта большого дампа;
• пользователь базы, способ аутентификации и права после переноса;
• кодировки соединения, базы, таблиц и отдельных колонок;
• сравнение выборок и бизнес-операций, а не только количество импортированных таблиц.

В актуальных требованиях Битрикса для MySQL 8.x указана кодировка utf8mb4 и сортировка utf8mb4_0900_ai_ci. Сам MySQL также рекомендует utf8mb4, поскольку устаревший utf8 является псевдонимом трёхбайтового utf8mb3. Но массово конвертировать рабочую базу одной командой рискованно: изменение кодировки может затронуть длину индексов, порядок сортировки, сравнение строк и время блокировки больших таблиц.

Сначала составляют отчёт по фактическим кодировкам, выбирают целевую схему и проверяют преобразование на копии. После импорта важно сравнить названия, поиск, фильтры, уникальные поля, свойства каталога и данные с символами вне базового набора. Успешный запуск MySQL ещё не доказывает, что значения сохранились и сравниваются ожидаемо.

Безопасная последовательность обновления

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

1. Зафиксировать исходное состояние. Версии, конфигурации, расписания, контрольные URL, формы, заказы и текущие ошибки.
2. Восстановить тестовую копию. Проверить, что резерв действительно содержит проект и запускается в изолированном окружении.
3. Подготовить код и переключить PHP. Обновить совместимые модули, исправить собственный код, проверить веб и CLI.
4. Обновить базу по поддерживаемому пути. Выполнить предварительные проверки, импорт или upgrade, проверить кодировки и запросы.
5. Пройти бизнес-сценарии. Сравнить результат с исходной матрицей, просмотреть логи и нагрузку.
6. Повторить процедуру на рабочем контуре. Назначить окно работ, сделать финальную копию, ограничить запись, переключить и наблюдать.

Если проект переносится на новый сервер, старое окружение удобно некоторое время сохранять выключенным, но готовым к возврату. В этом случае перенос и обновление сайта на 1С-Битрикс становятся одной управляемой работой: новый контур проверяется заранее, а DNS или прокси переключаются после приёмки.

Что проверить сразу после запуска

Первый ответ 200 OK подтверждает только то, что веб-сервер смог отдать страницу. Приёмка должна повторять реальные действия посетителя, менеджера и фоновой системы.

• Публичная часть: главная, разделы, карточки, поиск, файлы, изображения, редиректы и страницы 404.
• Административная часть: вход, редактирование элемента, загрузка файла, очистка кеша и проверка системы.
• Формы: серверное сохранение результата, почтовое событие, SMTP и обработка ошибки доставки.
• Интернет-магазин: цены, остатки, корзина, доставка, оплата, создание заказа и уведомления.
• Интеграции: тестовая заявка в CRM, обмен с 1С, callback оплаты и повтор запроса после временной ошибки.
• Фоновые задания: cron, агенты, резервирование, очистка и расписания импорта.
• Наблюдение: PHP-логи, медленные запросы, CPU, память, диск и время ответа до и после обновления.

Замеры производительности нужны даже тогда, когда ошибок нет. Новая версия может изменить план запроса, потребление памяти или поведение OPcache. Сравнивать лучше одинаковые URL и сценарии под одинаковой нагрузкой. Если после миграции сайт стал заметно медленнее, поможет отдельная диагностика производительности 1С-Битрикс, а не случайное увеличение всех серверных лимитов.

Как должен выглядеть план отката

Откат готовят до переключения. Для базы данных это особенно важно: понижение версии MySQL на месте обычно не является поддерживаемым обратным действием. Возврат означает запуск старого окружения и восстановление файлов с дампом, созданным до обновления.

В плане фиксируют:

• критерии остановки: белый экран, потеря заказов, ошибки записи, неработающая оплата или обмен;
• точное расположение проверенной копии и конфигураций;
• последовательность возврата веб-сервера, PHP, базы и фоновых заданий;
• предельное время диагностики до решения об откате;
• способ сохранить новые данные, появившиеся после переключения;
• ответственного, у которого есть независимый доступ к серверу.

Плохой план звучит как «если что, вернём версию в панели». Хороший позволяет выполнить возврат по шагам без доступа к административной части Битрикса. Если ошибка уже появилась на рабочем сайте, лучше зафиксировать симптом и логи, затем выполнять диагностику и исправление ошибки, а не многократно переключать версии вслепую.

Когда обновление стоит доверить разработчику

Самостоятельное переключение допустимо для простого, регулярно обновляемого проекта с проверенной копией и понятным набором модулей. Разработчик нужен, если сайт давно не обновлялся, работает на PHP 7.x или старше, использует MySQL 5.7, содержит правки ядра, собственные модули, интернет-магазин или несколько интеграций.

Задача также становится проектной, когда:

• нет тестового контура и подтверждённого восстановления;
• хостинг меняет сразу операционную систему, PHP и базу;
• невозможно остановить приём заказов на длительное время;
• объём базы не позволяет быстро повторить импорт;
• после переключения ошибки возникают только в cron, обмене или редких административных действиях;
• нужно перейти с устаревшей кодировки и проверить данные.

В рамках поддержки сайта на 1С-Битрикс обновление можно превратить в повторяемый процесс: вести карту окружения, регулярно проверять резервные копии, планировать версии заранее и не ждать ультиматума от хостинга.

FAQ

Можно ли просто переключить PHP в панели хостинга?

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

Нужно ли одновременно обновлять PHP, MySQL и ядро Битрикса?

Обычно нет. Лучше подготовить совместимые версии ядра и модулей, затем отдельно проверить PHP и только после этого менять СУБД. Одновременное изменение допустимо при миграции на новый контур, но внутри неё всё равно должны оставаться отдельные контрольные этапы.

Какую версию PHP выбирать для 1С-Битрикс в 2026 году?

Официальный минимум с февраля 2026 года — PHP 8.2, рекомендуемая версия — 8.4 и выше. Конкретную ветку выбирают после проверки версии Битрикса, модулей и хостинга. Формальное соответствие требованиям не заменяет тест проекта.

Можно ли перейти с MySQL 5.7 сразу на 8.4?

Официальный путь обновления предусматривает промежуточную ветку MySQL 8.0, затем 8.4. Для миграции через логический дамп всё равно нужно проверить совместимость схемы и данных, запустить Upgrade Checker и отрепетировать процедуру на тестовой установке.

Нужно ли сразу переводить все таблицы в utf8mb4?

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

Что делать, если после обновления сайт работает, но cron перестал запускаться?

Проверьте путь к CLI PHP, доступные ему расширения, пользователя запуска, права на файлы, рабочий каталог и журнал задания. Веб-сайт и cron могут использовать разные бинарники и разные файлы конфигурации.

Сколько должен храниться старый контур?

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

Вывод

Обновление PHP и MySQL для 1С-Битрикс — это миграция совместимого рабочего окружения, а не замена двух номеров версии. Надёжная последовательность выглядит так: инвентаризация, проверенное восстановление, отдельное тестирование PHP, поддерживаемый путь обновления базы, сценарная приёмка и готовый возврат.

Работу можно считать завершённой, когда открываются не только страницы, но и административная часть, формы, каталог, заказ, оплата, обмены и cron; в логах не появляются новые ошибки, а производительность не ухудшилась неожиданно. Такой подход требует подготовки, зато делает обновление контролируемой технической задачей вместо аварийного эксперимента на рабочем сайте.