Беру задачи в работу — отвечаю в течение дня
Бесплатная первичная оценка. Отвечу в течение дня. Работаю с Битрикс с 2010 года.
Сценарии
После переноса или смены хостинга сайт выдаёт «Error establishing a database connection». Файлы на месте, а сайт не работает.
После обновления MySQL с 5.7 на 8.0 часть страниц перестала работать. Каталог не отображается, фильтры ломаются.
Сервер аварийно перезагрузился — теперь MySQL выдаёт «Table is marked as crashed» или не может запуститься.
Страницы открываются по 10-15 секунд, каталог зависает. Хостер говорит, что MySQL перегружен.
После обмена с 1С или обновления появились дубли товаров, ошибки «Duplicate entry», цены расходятся с учётной системой.
Пытались восстановить сайт из дампа — часть данных потеряна, таблицы отсутствуют, сайт работает с ошибками.
Не нашли свой случай? Проблем с базой данных больше десятка типов. Опишите ситуацию, и я определю, что именно случилось.
Разбор эксперта
Битрикс хранит в MySQL всё: товары, заказы, пользователей, настройки модулей, права доступа. Это сотни связанных таблиц, где изменение в одной влияет на десятки других. Когда что-то ломается, последствия расползаются по всему сайту — от каталога до корзины.
Сообщение «ошибка базы данных» может означать проблему с конфигурацией подключения, сбой MySQL-сервера, повреждение файлов InnoDB, нехватку дискового пространства, конфликт версий или десяток других причин. Каждый класс требует своих инструментов диагностики и подхода к решению.
Специалист не угадывает причину — он анализирует error.log MySQL, проверяет состояние InnoDB через SHOW ENGINE INNODB STATUS, изучает slow query log и нагрузку на сервер. Перед любым вмешательством — бэкап. Это занимает больше времени, чем «быстрый REPAIR», но сохраняет данные.
Процесс
Расскажите, что произошло: какая ошибка появляется, когда это началось, был ли перенос, обновление MySQL или сбой на сервере. Первичная оценка — бесплатно. Я отвечу в течение дня и скажу, что потребуется для решения.
Анализ логов MySQL, проверка конфигурации подключения, состояние таблиц и индексов, нагрузка на сервер. Определю точную причину — от некорректного .settings.php до повреждённого tablespace InnoDB. Если обнаружатся дополнительные проблемы — сообщу сразу.
Называю стоимость и сроки до начала работ. Вы всегда знаете заранее, сколько это будет стоить. Если в процессе выясняются новые обстоятельства — согласуем отдельно, аргументированно и прозрачно.
Проверяю работоспособность сайта, убеждаюсь, что проблема устранена. 14 дней гарантии — если проблема вернётся без изменений в коде с вашей стороны, исправлю бесплатно.
Первичная оценка — бесплатно
Кейсы
Администратор сменил пароль MySQL-пользователя через панель управления хостингом. Сайт сразу перестал работать — «Error establishing a database connection».
Новый пароль обновился в панели хостинга, но не в конфигурации Битрикс. Файл .settings.php содержал старые учётные данные. Дополнительно в dbconn.php (старый формат) был прописан другой хост подключения.
Диагностика 15 минут, устранение 30 минут. Учётные данные синхронизированы в обоих конфигурационных файлах, проверена работоспособность всех модулей.
Хостер перевёл сервер с MySQL 5.7 на 8.0. Главная страница работала, но каталог товаров и фильтры выдавали ошибку. Поиск по сайту тоже не работал.
В MySQL 8.0 по умолчанию включён sql_mode=ONLY_FULL_GROUP_BY. Десятки SQL-запросов Битрикс и кастомных компонентов использовали GROUP BY без перечисления всех неагрегированных столбцов. Дополнительно изменилось поведение сортировки по умолчанию (utf8mb4_0900_ai_ci).
Диагностика 1 час, устранение 5 часов. Критичные запросы исправлены, sql_mode настроен с учётом совместимости, collation приведён к единому стандарту.
Сервер аварийно перезагрузился из-за сбоя питания. После запуска сайт открывался, но корзина и оформление заказа не работали — MySQL выдавал ошибку.
Три таблицы модуля интернет-магазина (b_sale_basket, b_sale_order, b_sale_fuser) использовали устаревший движок MyISAM, который не защищён от некорректного завершения. Индексные файлы .MYI повреждены при аварийном отключении.
Диагностика 30 минут, устранение 2 часа. Таблицы восстановлены через REPAIR TABLE, затем сконвертированы в InnoDB для защиты от повторных сбоев.
После очередного обновления хостера MySQL перестал запускаться. В логах — ошибки InnoDB. Сайт полностью недоступен уже второй день.
Повреждён системный tablespace ibdata1. Автоматическое восстановление InnoDB (crash recovery) не справилось — требовался принудительный режим. Проблему усугубил переполненный /tmp, из-за которого MySQL не мог создать временные файлы.
Диагностика 1 час, устранение 4 часа. Пошаговое восстановление через innodb_force_recovery (уровни 1→3), экспорт данных, пересоздание tablespace, импорт. Потерь данных нет.
Ночной обмен с 1С прервался на середине из-за таймаута. Утром менеджеры обнаружили дублирующиеся заказы в CRM и ошибки «Duplicate entry» при попытке создать новые заказы.
Прерванная транзакция импорта оставила частично записанные данные в b_sale_order и b_sale_basket. Автоинкрементные ID рассинхронизировались, новые записи конфликтовали с «мусорными» данными прерванного импорта.
Диагностика 40 минут, устранение 3 часа. Удалены некорректные записи, восстановлена целостность AUTO_INCREMENT, настроен транзакционный импорт с откатом при ошибке.
После взлома сайт восстановили из дампа, но половина статей и все изображения в каталоге услуг исчезли. Бэкап оказался неполным.
Дамп был создан утилитой mysqldump без параметра --routines --triggers и с ограничением по размеру пакета. Таблицы b_iblock_element_prop_s* (свойства инфоблоков с контентом) не вошли в дамп из-за превышения max_allowed_packet. Об ошибке при создании дампа никто не знал.
Диагностика 1.5 часа, устранение 6 часов. Данные частично восстановлены из фрагментов старого дампа и кеша поисковых систем. Настроен корректный бэкап с проверкой целостности.
После переноса сайта на новый сервер все русские тексты в каталоге стали отображаться как «????». Новые товары добавляются корректно, но старые — нечитаемы.
При миграции дамп был создан в кодировке utf8, а восстановлен на сервере с кодировкой по умолчанию utf8mb4. Несовпадение collation привело к потере многобайтовых символов в существующих данных. CONNECTION_CHARSET в .settings.php не был обновлён.
Диагностика 45 минут, устранение 4 часа. Конвертация данных через промежуточную latin1-кодировку, настройка единой кодировки utf8mb4 на уровне сервера, подключения и таблиц.
На коробочном Битрикс24 с двумя серверами БД менеджеры стали замечать, что данные CRM отличаются в зависимости от того, с какого компьютера смотришь. Сделки пропадали и появлялись.
Реплика MySQL отстала от мастера на 12 часов. Причина — long-running запрос аналитического модуля заблокировал репликацию. Битрикс24 направлял часть читающих запросов на отставшую реплику.
Диагностика 1 час, устранение 3 часа. Репликация восстановлена, аналитический запрос оптимизирован, настроен мониторинг отставания реплики с алертами.
В часы пик покупатели жаловались, что при оформлении заказа страница зависала на 30-60 секунд. Часть заказов терялась. Проблема повторялась каждый вечер.
Таблицы b_sale_basket и b_sale_fuser работали на движке MyISAM, который использует табличные блокировки. При 15+ одновременных покупках INSERT в одну таблицу блокировал все SELECT, создавая цепочку ожидания.
Диагностика 40 минут, устранение 2 часа. Таблицы сконвертированы в InnoDB (построчные блокировки), проверены и перестроены индексы. Зависания прекратились.
Портал с историей закупок за 10 лет стал работать невыносимо медленно. Поиск по реестру — 30-40 секунд. Пользователи уходили, не дождавшись результата.
Таблица b_iblock_element выросла до 8 миллионов строк. Составные запросы каталога не использовали индексы — три ключевых индекса отсутствовали, один был фрагментирован на 87%. EXPLAIN показывал полное сканирование таблицы на каждый запрос.
Диагностика 2 часа, устранение 5 часов. Созданы составные индексы по полям фильтрации, перестроены фрагментированные индексы, настроен innodb_buffer_pool_size под объём данных. Время ответа каталога — менее 2 секунд.
Стоимость
бесплатно
Вы описываете проблему, я оцениваю ситуацию и говорю, что потребуется. Без обязательств.
от 7 000 ₽
Минимальный заказ — 2 часа. С третьего часа — 3 500 ₽/час. Точную стоимость называю до начала работ, после диагностики.
по запросу
Для регулярного сопровождения. Ниже стоимость часа, квант времени 30 минут, нет минимального заказа.
Смотреть пакеты услугНе починил — не платите. Стоимость всегда согласована до начала работ. Никаких сюрпризов в счёте.
FAQ
Ответы на типичные ситуации с ошибками базы данных на Битрикс
Контакт
Опишите, что произошло — какую ошибку выдаёт сайт, когда это началось и что изменилось перед этим. Я оценю ситуацию и скажу, что потребуется для восстановления.