Обновление таблиц mysql может сопровождаться вылетом веб-приложения по таймауту. Почему? Потому что таблица слишком велика и скрипт не успевает ее обновить. Что же делать, если нам нужно перейти на новую мажорную ветку Openx|Revive-Adserver? Скорее всего ваша БД слишком велика и конвертация не успевает завершиться до окончания работы скрипта
Обновление таблиц mysql может сопровождаться вылетом веб-приложения по таймауту. Почему? Потому что таблица слишком велика и скрипт не успевает ее обновить. Что же делать, если нам нужно перейти на новую мажорную ветку Openx|Revive-Adserver? Скорее всего ваша БД слишком велика и конвертация не успевает завершиться до окончания работы скриптаПоэтому я предлагаю несколько не сильно хитрых действий, которые могут пригодиться в этом случае
На стороне БД
- Таблицы data_raw_% могут быть слишком велики. Таким образом имеет смысл очистить эти таблицы от старой статистики выполнением maintanance скриптов
- Возможно статистика за годы не нужна, а достадочно будет за два последних месяца, тогда удаляем лишнее
- Можно очистить таблицу userlog от ненужных записей
- Выполнить optimize table больших таблиц и таблиц из которых удалили лишнее
- Можно создать пустой файл NOBACKUPS в папке var/. Таким образом мастер обновления не будет создавать резервной копии БД
На стороне веб-сервера, на время обновления ставим
В php.ini
memory_limit = -1 (без ограничений) max_execution_time = 0 (без ограничений) max_input_time = -1 (без ограничений)
В httpd-default.conf
Timeout 36000 (10 часов, думаю достадочно)
Если используется nginx+php-fpm, то поправить php.ini как указано выше + смена параметров как указано ниже
В php-fpm.ini
request_terminate_timeout = 36000
В nginx’е, в конфиге виртуального сайта в location~ \.php$ добавить
fastcgi_read_timeout 36000;
После обновления не забываем вернуть этим параметрам первоначальные значения
П.С.
Бекапы как БД, так и исходников сайта никто не отменял
- Системный администратор с 2000 года
- Участник Хабр Q&A и cyberforum
- Кейсы
