Magento MySQL ушел ошибка

14

У меня множество странных проблем с Magento CE 1.7.0.2. Во время обычной работы на сайте иногда появляется страница с ошибками Magento ( при обработке вашего запроса произошла ошибка ) как на веб- интерфейсе, так и на бэкэнде. Просматривая связанный отчет, я вижу следующее сообщение:

"SQLSTATE[HY000] [2006] MySQL server has gone away"

Иногда, но реже, сообщение отчета будет выглядеть так:

 Connection reset by peer

Я посмотрел на var> log> system.log, и MySQL has gone awayошибка сопровождается следующим:

Warning: PDO::__construct(): MySQL server has gone away  in /var/www/html/domain.com/live/lib/Zend/Db/Adapter/Pdo/Abstract.php on line 129
Error while reading greeting packet. PID=1863  in /var/www/html/domain.com/live/lib/Zend/Db/Adapter/Pdo/Abstract.php on line 129

В дополнение к этому, похоже, что при каждом запросе возникает следующая ошибка MySQL has gone away:

 Warning: include(File.php): failed to open stream: No such file or directory  in /var/www/html/domain.com/live/lib/Varien/Autoload.php on line 93
 Warning: include(): Failed opening 'File.php' for inclusion

Я просмотрел большинство статей, которые могу найти по этому поводу, и возился с параметрами базы данных, пока коровы не вернулись домой, но ошибка остается.

После следующего QnA о компиляторе я заметил, что страница администратора Система> Инструменты> Компиляция полностью пуста. Я думаю, что это все связанные ошибки, но любое понимание отладки или причин было бы очень полезно.

Я прошу прощения, если это бессвязно; Я не спал около 42 часов, поэтому, пожалуйста, попросите разъяснений. Спасибо.

-- Обновить --

Мой серверный стек для наглядности:

PHP 5.5.4 (PHP-FPM)
Nginx 1.4.2
MySQL 5.5.33

-- Обновить --

Мне пришло в голову (после некоторого сна), что я никогда не указывал - база кода PHP и база данных MySQL находятся на отдельных аппаратных серверах - очень важно знать, собираетесь ли вы мне помочь !! Я приношу извинения.

Jongosi
источник
1
Вы используете постоянные соединения с базой данных? Если это так, попробуйте отключить их. Я также проверил бы журналы mysql, чтобы увидеть, есть ли там ошибки или действительно ли он перезапускается, а просто разрывается соединение.
Давидгер
Спасибо Дэвиду, следящему за журналами MySQL, и БД никогда не ударится при возникновении ошибки. Я использовал постоянные соединения, отключение не помогло :(
Jongosi
1
Считаете ли вы, что связь плохая. Причиной этой ошибки является то, что БД не получила сообщение. Попробуйте отладку, используя информацию о соединении из local.xml для вызова функций mysqli. Посмотри что получится.
SH-
спасибо, похоже, исправил мою проблему с редактированием локального файла

Ответы:

9

Это в основном связано с одной из двух причин ниже

  1. Тайм-аут сервера и соединение закрыто.
    исправить: попробуйте увеличить wait_timeoutпеременную в my.cnf/my.ini файле конфигурации вашего mysqld .
  2. Сервер сбросил неверный или слишком большой пакет.
    исправлено: увеличение максимального размера пакета путем увеличения значения max_allowed_packetв my.cnf/my.ini файле.

Пожалуйста, проверьте файлы, если вы пытаетесь получить что-то, что занимает слишком много времени или неприменимо.

Аншу Мишра
источник
Спасибо Anshu, я слежу за журналом запросов MySQL, и база данных никогда не попадает под запрос. Кроме того, если я перезагружаю сервер, иногда может произойти ошибка в течение 20 секунд после того, как сервер подключен к сети - это слишком мало для тайм-аута даже настроек по умолчанию. Я установил max_allowed_packet2G и wait_timout86400, но все равно ничего не помогло.
Jongosi
Пожалуйста, проверьте правильность подключения к базе данных, проверьте файл app / etc / local.xml
Anshu Mishra
Спасибо Anshu, да, это правильно - соединение происходит около 68% запросов
Jongosi
6

Проблема решена! Спасибо всем за помощь. Это была проблема аппаратного брандмауэра с веб-хостом, даже после того, как они были отключены нами.

Как подтверждает команда серверов 1 & 1 , аппаратные брандмауэры были правильно настроены, но они неправильно перехватывали действительный трафик между файловым сервером и сервером БД примерно в 25% случаев.

Вместо этого мы настроили iptables и полностью отключили аппаратные брандмауэры. 100% доступность сейчас.

Jongosi
источник
2
Боже мой! Спорадический брандмауэр ... должен любить такого рода проблемы. Рад, что вы получили это отсортировано. :)
Давидгер
Та же проблема здесь, и, похоже, ваше решение сработает и для нас. Буду говорить 1 и 1 тоже. Служба поддержки помогла вам в любом случае? Могу ли я связаться с вами? Twitter? Facebook? Пожалуйста, смотрите мой профиль для деталей. Спасибо
webDEVILopers
2

У меня возникла та же проблема с Magento 2.1, и мой журнал ошибок mysql показал следующую ошибку несколько раз во время процесса «MySQL ушел»:

...[Warning] File Descriptor 1228 exceeded FD_SETSIZE=1024

Чтобы потенциально решить эту проблему, сначала проверьте open filesзначение с $ ulimit -n, которое в моем случае было 256.

Во-вторых, добавьте table_open_cache = {that ulimit -n value}в [mysqld]разделе в вашем my.cnf.

Теперь перезапустите MySQL и, надеюсь, вы вернулись к действию.

Примечание: я запускаю Magento 2.1 локально на OS X El Capitan с PHP 7.1 и сборкой MySQL 5.7.15 с Homebrew. Но я уверен, что это решение будет работать и на старых или на других установках.


источник
1

Отредактируйте файл app / etc / local.xml в папке Magento, заменив запись для хоста на «127.0.0.1» вместо «localhost».

BROC
источник
База данных находится на отдельном аппаратном сервере, поэтому используется IP-адрес сервера MySQL.
Jongosi
1

Произошла та же ошибка при переносе большой базы данных между 2 серверами.

Временное добавление следующего кода в файл конфигурации mysql (/etc/mysql/my.cnf) на моем локальном (целевом) сервере и перезапуск mysql (перезапуск службы mysql) устранило проблему для меня:

max_allowed_packet      = 160M
wait_timeout            = 28800000
Майкл
источник