Подтвердить что ты не робот

ERROR 2013 (HY000): Потерянное соединение с сервером MySQL в пакете авторизации чтения, системная ошибка: 0

Я получаю следующую ошибку

ERROR 2013 (HY000): Lost connection to MySQL server at 
'reading authorization packet', system error: 0

при попытке подключиться к моему серверу MySQL.

Что я делаю:

  • У меня есть репликация Master-Slave в MySQL, которая работает и просто добавляет возможности баланса нагрузки, используя F5.
  • Я настроил F5 в соответствии с их сайтом.

Но когда я пытаюсь подключиться к моему серверу MySQL, используя IP-адрес, который был настроен F5, я получаю

ERROR 2013 (HY000): Lost connection to MySQL server at 
'reading authorization packet', system error: 0 

Любые идеи?


Обновление моего хода: ZERO
- Я получаю ту же ошибку Я не получаю никаких записей в /var/log/secure, как если бы кто-то попытался аутентифицировать следующую форму ip, где я создал свой сервер баланса нагрузки.
В журнал ошибок mysql не входит. Команда - ничего не возвращает

mysql> SHOW GLOBAL STATUS LIKE 'Aborted_connections';
Empty set (0.00 sec)

Я уже изменил свой файл my.cnf и добавил

[mysqld]
skip-name-resolve

Отмените connect_timeout до 10.
 Так что кажется, что я не получаю ответа на сервер, который я создал на своем F5
Я, наконец, убедил администратора F5 передать мне журнал для сервера F5, и я просмотрел все, что мне нужно. Вот результат:

  Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_ACCEPTED>: BIG-IP MySQL Proxy -- clientside initial connection
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_ACCEPTED>: BIG-IP MySQL Proxy -- clientside responding with server WELCOME packet
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_DATA>: BIG-IP MySQL Proxy -- clientside authenticated flag not set
Jan 28 15:46:39 tmm err tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_DATA>: BIG-IP MySQL Proxy -- mysql client: attempting to do something before authentication
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <LB_SELECTED>: BIG-IP MySQL Proxy -- serverside selected pool /Common/foss-mysql-slave_pool node SLAVE-IP
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <CLIENT_CLOSED>: BIG-IP MySQL Proxy -- clientside connection closed from MASTER-IP(XXXXXXX)
Jan 28 15:46:39 tmm debug tmm[6459]: Rule /Common/iRule-f5_mysql_proxy <SERVER_CLOSED>: BIG-IP MySQL Proxy -- serverside connection closed from node SLAVE-IP(XXXXXXXX)

Я заменил ip ради безопасности!

как дополнительный - и я думаю, что здесь проблема - моя версия mysql 5.1.69-log спасибо All

4b9b3361

Ответ 1

Из документации:

Реже, это может произойти, когда клиент пытается выполнить начальную подключение к серверу. В этом случае, если ваше значение connect_timeout устанавливается всего на несколько секунд, вы можете решить проблему увеличив его до десяти секунд, возможно, больше, если у вас очень длинный расстояние или медленное соединение. Вы можете определить, являетесь ли вы испытывая эту более необычную причину, используя SHOW STATUS LIKE 'aborted_connections'. Он будет увеличиваться на единицу для каждого начального попытка соединения с сервером прерывается. Вы можете видеть "чтение пакет авторизации" как часть сообщения об ошибке, и если это так, предполагает, что это необходимое вам решение.

Попробуйте увеличить connect_timeout в файле my.cnf

Другой стиль:

MySQL: Потерянное соединение с сервером MySQL при чтении исходного пакета связи

  • В какой-то момент удаленные клиенты не могли подключиться к сервер MySQL.

  • Клиент (некоторое приложение на платформе Windows) дал неопределенный описание как Connection unexpectedly terminated.

  • При удаленном входе в систему с клиентом MySQL следующая ошибка появился:

    ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0

В FreeBSD это происходит потому, что в /etc/hosts.allow. не найдено совпадения. Добавляем следующую строку до того, как строка, выражающая ALL:ALL, исправляет это:

mysqld: ALL: allow

В системах Unix FreeBSD Unix стоит проверить файлы /etc/hosts.allow и /etc/hosts.deny. Если вы ограничиваете соединения, убедитесь, что эта строка находится в /etc/hosts.allow:

mysqld: ALL

или проверьте, указан ли хост в /etc/hosts.deny.

В Arch Linux аналогичная строка может быть добавлена ​​в /etc/hosts.allow:

mysqld: ALL

Ответ 2

Это обычно вызвано прерыванием соединения. Вы можете проверить это, установив статус:

mysql> SHOW GLOBAL STATUS LIKE 'Aborted_connects';

Если этот счетчик продолжает увеличиваться по мере того, как вы получаете потерянные соединения, это знак, с которым у вас возникают проблемы во время подключения.

Одним из средств защиты, которое, как представляется, работает во многих случаях, является увеличение тайм-аута. Рекомендуемое значение составляет 10 секунд:

mysql> SET GLOBAL connect_timeout = 10;

Другой распространенной причиной таймаутов подключения является обратный DNS-поиск, который необходим при аутентификации клиентов. Рекомендуется запустить MySQL с переменной config в my.cnf:

[mysqld]
skip-name-resolve

Это означает, что ваши операторы GRANT должны быть основаны на IP-адресе, а не на имени хоста.


Я также нашел этот отчет с 2012 года на сайте f5.com(теперь он защищен логином, но я получил его через кеш Google)

Вероятно, прокси не будет работать, если вы не используете BIG-IP 11.1 и MySQL 5.1, которые были версиями, которые я тестировал. У протокола MySQL есть привычка к изменению.

Я предлагаю вам связаться с F5 Support и подтвердить, что вы используете поддерживаемую комбинацию версий.

Ответ 3

Мое дело было в том, что сервер не принял соединение с этим IP-адресом. Сервер - это SQL-сервер из Google Apps Engine, и вам нужно настроить разрешенные удаленные хосты, которые могут подключаться к серверу.

Добавление (нового) узла на страницу администратора GAE решило проблему.

Ответ 4

Я много боролся с этой ошибкой. Пробовал каждый ответ, который я нашел в Интернете.

В конце концов, я подключил свой компьютер к своей горячей точке сотового телефона, и все сработало. Я выяснил, что мой интернет-сайт блокирует связь с MySQL.

Это не полное решение, но, возможно, кто-то сталкивается с той же проблемой. Стоит проверить соединение.

Ответ 5

Я использую несколько соединений mysql (подключение к различным наборам баз данных) в localhost.

Это случилось со мной после того, как я закрыл свой компьютер, и mysql не был должным образом выключен. После запуска моей машины я смог успешно подключиться к нескольким соединениям db, кроме одного (я использовал это задолго до завершения работы компьютера). В соответствии с инструкциями в этих сообщениях я удвоил connect_timeout, но я не смог подключиться к этому соединению с базой данных.

Я перезапустил свою машину и теперь могу успешно подключиться. Это поможет вам разблокировать себя, но было бы здорово, если бы его можно было зафиксировать без перезагрузки машины.

Еще одна проблема: connection_timeout, как мне показалось, задерживает связанную проблему, но я сразу получал ошибку в локальном хосте, когда в уравнении нет сети.

Ответ 6

Я решил это, несколько раз остановив mysql.

$ mysql.server stop
Shutting down MySQL
.. ERROR! The server quit without updating PID file (/usr/local/var/mysql/xxx.local.pid).
$ mysql.server stop
Shutting down MySQL
.. SUCCESS! 
$ mysql.server stop
ERROR! MySQL server PID file could not be found! (note: this is good)
$ mysql.server start

Все хорошо отсюда. Я подозреваю, что mysql был запущен не один раз.

Ответ 7

Другой возможностью может быть соединение reset с обертками TCP (/etc/hosts.deny и /etc/hosts.allow). Просто проверьте, что происходит с telnet до порта 3306 - если это ничего, тогда есть что-то в середине, предотвращающее общение.

Ответ 8

У меня есть mac, но предполагаю, что все linux одинаковы для этой части...

В моем случае я получил следующее:

2018-12-03 11:13:27 - Start server: 
2018-12-03 11:13:27 - Server start done.
2018-12-03 11:13:27 - Checking server status...
2018-12-03 11:13:27 - Trying to connect to MySQL...
2018-12-03 11:13:27 - Lost connection to MySQL server at 'reading authorization packet', system error: 0 (2013)
2018-12-03 11:13:27 - Assuming server is not running

Я запустил это:

sudo killall mysqld

А затем снова начал mysql через mysqlworkbench, хотя в вашем случае это может быть так:

mysql.server start

* sidenote: Я попытался запустить mysql.server stop и получил это Shutting down MySQL.... SUCCESS! но после запуска ps aux | grep mysql ps aux | grep mysql Я видел, что он действительно не закрыт...

Ответ 9

В моем случае это произошло, когда было много соединений с сервером MySQL (15 000 подключений), а свободная память составляла около 120 МБ. После того, как я добавил больше памяти на сервер, ошибка исчезла.

Ответ 10

Если вы получаете это при использовании DevDesktop - просто перезапустите DevDesktop!