Столкнулся с интересной ситуацией при обновлении портала. В какой-то момент установка просто зависает на CRM-модуле (24.300.0), а потом портал уходит в 502 или 504 ошибку.

Я сразу начал перебирать стандартные причины: 🔹Ресурсов сервера достаточно? сервер не упирается, CPU и память свободны? 🔹Таймауты в nginx, Apache и php.ini выставлены щедро? 🔹Весь кастом временно отключён, local переименован? 🔹Установка идёт полностью стандартным способом, без ручного копирования или подмены файлов?

Казалось бы, все условия соблюдены… но обновления упрямо не устанавливаются

Тогда я задумался: а что именно сейчас делает обновление? Где оно спотыкается?

Ответ оказался в базе. Оказалось, при обновлении CRM выполняется вот такой SQL-запрос: ALTER TABLE b_crm_act MODIFY OWNER_TYPE_ID INT(1) NOT NULL;

И если в CRM накопилось много активностей, таблица b_crm_act разрастается до внушительных размеров. Из-за этого SQL-операция просто не успевает завершиться в отведённое время — особенно на неторопливых VPS/VDS.

Решение оказалось до смешного простым: Выполнил этот запрос вручную через консоль MySQL под админом. Подождал, пока он отработает, и снова запустил обновление. Главное, делать это только после резервной копии, не шутите с базой.

Если во время обновления Битрикс24 ловите 502/504, а в логах мелькают MySQL sserver has gone away или upstream timed out — стоит проверить, не застопорилось ли обновление на тяжёлой операции в БД. В таких случаях помогает внимательнее посмотреть, какой именно шаг выполняет апдейтер, и при необходимости слегка подтолкнуть его вручную.