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
Ответы
Ответ 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!