Плагин яндекс деньги wordpress. Яндекс.Касса для WooCommerce
Все изложенное в данном разделе относится также и к родственной ошибке Lost connection to server during query .
Наиболее часто ошибка MySQL server has gone away возникает в результате тайм-аута соединения и его закрытия сервером. По умолчанию сервер закрывает соединение по прошествии 8 часов бездействия. Можно изменить лимит времени, установив при запуске mysqld переменную wait_timeout .
Другой распространенной причиной получения ошибки MySQL server has gone away является выдача команды "закрытия" на соединении MySQL с последующей попыткой выполнить запрос на закрытом соединении.
Если это получено в скрипте, то достаточно просто повторить запрос от клиента, чтобы соединение автоматически восстановилось.
Обычно в этом случае выдаются следующие коды ошибки (какой из них вы получите, зависит от ОС):
Ошибка будет также выдана, если кто-нибудь уничтожит выполняющийся поток посредством kill номерпотока.
Проверить, что MySQL на ходу, можно, запустив mysqladmin version и изучив время работы (uptime). Если проблема в аварийном завершении mysqld , то необходимо сосредоточиться на поиске причины аварии. В этом случае следует сначала проверить, не будет ли уничтожен MySQL снова при повторном задании запроса (see section ).
Эти ошибки будут также выдаваться при посылке серверу неверного или слишком длинного запроса. Если mysqld получает неправильный или слишком большой пакет, то сервер предполагает, что с клиентом что-то не так, и закрывает соединение. Если необходимо выполнять объемные запросы (например, при работе с большими столбцами типа BLOB), можно увеличить предельный размер запроса, запустив mysqld с опцией -O max_allowed_packet=# (по умолчанию 1 Mб). Дополнительная память выделяется по требованию, так что mysqld будет использовать больше памяти только в случае, когда выдан большой запрос или когда mysqld должен возвратить большую строку результата!
Если у вас возникнет желание сделать отчет об ошибке по этой проблеме, то не забудьте включить в него следующие сведения:
- Информацию о том, упал MySQL или нет (это можно определить по файлу hostname.err (see section A.4.1 Что делать, если работа MySQL сопровождается постоянными сбоями).
- Если определенный запрос уничтожает mysqld , а используемые в нем таблицы перед выполнением запроса проверялись с помощью CHECK TABLE , то желательно составить контрольный тест (see section E.1.6 Создание контрольного примера при повреждении таблиц).
- Значение переменной wait_timeout в сервере (это значение выдает mysqladmin variables).
- Информацию о том, пробовали ли вы запускать mysqld с --log и проверять, появляется ли выданный запрос в журнале.
В логах ошибок PHP иногда можно встретить записи типа MySQL Server Has Gone Away (error 2006). Они означают, что соединение с сервером баз данных (ожидание сессии) прервалось по таймауту. Ошибку можно легко исправить.
Как исправить ошибку MySQL Server Has Gone Away
Ошибка MySQL Server Has Gone Away (error 2006) может возникнуть в двух случаях:
- Соединение с MYSQL прерывается по таймауту, передача данных не успевает завершится в рамках сессии.
- Пакет, который передается слишком большой или некорректный
Быстрым решением является увеличение значений двух глобальных переменных MySQL. Делается это в основном конфигурационном файле сервера баз данных /etc/mysql/my.cnf или в консоли MySQL авторизовавшись как root
В консоли это выглядит так:
set @@GLOBAL.max_allowed_packet=96000000;
set @@GLOBAL.wait_timeout=1000;
Решение с внесением изменений в файл /etc/mysql/my.cnf.
ВАРИАНТ 1 — Таймаут соединения С БД
Программный код может делать запрос в базу данных, который обрабатывается больше максимального времени выполнения запроса, установленного в конфигурационном файле. При этом срабатывает ограничение на время ожидания в сессии.
Лучше всего выяснить почему такие запросы имеют место и оптимизировать их, но для того чтобы получить мгновенный результат нужно увеличить значение параметра wait_timeout . Значение задается в секундах и не может быть более 28800.
mcedit /etc/mysql/my.cnf
wait_timeout = 1000
После внесения любых изменений в конфигурационный файл перезапускаем MySQL
/etc/init.d/mysql restart
ВАРИАНТ 2 — СЛИШКОМ Большой пакет
Несколько другая ситуация имеет место когда сервер отклоняет пакет из-за его слишком большого размера (или в случае если сервер не может распознать пакет по той или иной причине). В логи при этом пишутся точно такие же сообщения.
Решение в этом случае практически такое же — необходимо скорректировать значение одной переменной в конфигурационном файле.
mcedit /etc/mysql/my.cnf
max_allowed_packet = 96M
В примере задан максимальный размер пакета, который сервер не будет отвергать — 96 Мб. Устанавливать слишком большие значения не стоит.
Также перезапускаем MySQL
/etc/init.d/mysql restart
Таким образом, РНР ошибка mysql server has gone away в большинстве случаев побеждается корректировкой значений двух переменных и перезапуском сервера баз данных.
Эта статья может быть полезна тем, кто импортирует базы данных больших размеров на Denwer (либо на свой выделенный сервер). Допустим, размер Вашей базы 50 МБ . Просто через вставку запроса в phpMyAdmin в разделе "SQL " ничего не выйдет - браузер просто повиснет. Поэтому единственный выход - использовать импорт SQL-файла . Но тут Вас будет поджидать ошибка #2006 или server has gone away . Вот о решении этой проблемы я и расскажу в этой небольшой статье.
Самое первое, что Вы должны сделать - это настроить PHP для . Без этого по умолчанию Вы вообще не сможете загружать файлы размером, например, 50 МБ .
Дальше необходимо зайти в настройку MySQL (на Denwer это "usr\local\mysql-5.5\my.ini ") и там поменять значение параметра "max_allowed_packet " на, например, 100M , что соответствует 100 МБ :
Max_allowed_packet = 100M
После всего этого перезапустите MySQL (либо Denwer ), и больше ошибки 2006 или server has gone away возникать не будет. Если, конечно, Вы не захотите импортировать базу данных размером 150 МБ , тогда придётся снова увеличивать необходимые параметры в настройках PHP и MySQL .
Случается так, что разработчики на PHP встречаются с ошибкой, когда сервер баз данных MySQL при выполнении скриптов неожиданно "падает", выдавая ошибку с сообщением: "ERROR 2006 (HY000): MySQL server has gone away ". Сегодня мы разберем один из вариантов (или сценариев), когда это случается.
Один из клиентов нашего обратился к нам с подобной ошибкой с просьбой "объснить", почему такое происходит и почему "у нас ложится сервер?". Вследствии обработки его запроса выяснилось, что у клиента на одном из проектов выполнялся скрипт, который в течении 3 минут собирал статистику или ждал получение ответа от внешнего (стороннего) хоста, а затем скрипт должен был "положить" этот ответ в базу данных, т.е. сохранить этот ответ в заданной таблице.
При выполнении скрипта использовался примерно такой цикл, в котором делалась пауза в выполнении скрипта на 30 секунд:
// здесь уже должен быть ключ для извлечения результатов проверки текста на уникальность! $counter = 4; while ($counter > 0) { sleep(30) ; $checkResults = $plagiarism->getTextCheckResults($textUid); if ($checkResults instanceof \common\components\plagiarism\Text && $checkResults->
Т.е. скрипт пытался протестировать текст на уникальность за счет внешнего сервиса и делал 4 попытки через каждые 30 секунд. Однако когда скрипт уже получал успешный отклик от внешнего хоста в результатами, и пытался сохранить эти результаты в базы данных, вылезала подлая ошибка:
2016-01-30 22:32:05 exception "yii\base\Exception" with message "SQLSTATE: General error: 2006 MySQL server has gone away The SQL being executed was: SELECT * FROM `plagiarism` WHERE text_uid = "56ad0f99425bc"" in /home/mysite.ru/modules/client/controllers/CompanyController.php:150
Было очень много эмоций с самого разработчика, потому что по всем ожиданиям такого не должно было случиться!
Однако решенеи лежало под носом, и дело лишь заключалось в том, чтобы обратить внимание на значение одной глобальной серверной переменной MySQL, а именно на значение переменной connect_timeout = 10 (в секундах), которая отвечает за таймаут коннекта с MySQL-сервером. Т.е. если в течение этих 10 секунд работающий скрипт не пытается взаимодействовать с MySQL-сервером, это соединение рвется и его необходимо устанавливать заново !
Теперь вы понимаете, как надо изменить этот участок кода: нужно уменьшить время sleep(30) до значения, не превосхожящее 10 секунд . И - вуаля! Теперь все работает, как и ожидалось!
// здесь уже должен быть ключ для извлечения результатов проверки текста на уникальность! $counter = 10; while ($counter > 0) { sleep(9) ; // здесь происходит также сохранение полученного результат в БД! $checkResults = $plagiarism->getTextCheckResults($textUid); if ($checkResults instanceof \common\components\plagiarism\Text && $checkResults->check_result !== null) { break; } --$counter; }
Так что обращайте, пожалуйста, внмиание на такие вещи, потому что они совершенно не очевидны, и задумывайтесь о логике работы ваших скриптов в заданных конкретных условиях
