ОШИБКА 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
Есть идеи?
Обновленная информация о моем прогрессе: ноль
- я получаю ту же ошибку, я не получаю записей в /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 Thx All
15 ответов
В более редких случаях это может произойти, когда клиент пытается установить исходное соединение с сервером. В этом случае, если для вашего значения 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
На не-FreeBSD системах Unix стоит проверить файлы /etc/hosts.allow а также /etc/hosts.deny. Если вы ограничиваете соединения, убедитесь, что эта линия находится в /etc/hosts.allow:
mysqld: ALL
или проверьте, указан ли хост в /etc/hosts.deny.
В Arch Linux подобная строка может быть добавлена к /etc/hosts.allow:
mysqld: ALL
Обычно это происходит из-за прерванного соединения. Вы можете убедиться в этом, проверив статус:
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 и подтвердить, что вы используете поддерживаемую комбинацию версий.
Я много боролся с этой ошибкой. Пробовал каждый ответ, который я нашел в Интернете.
В конце концов, я подключил свой компьютер к точке доступа своего мобильного телефона, и все заработало. Я выяснил, что интернет моей компании блокирует соединение с MySQL.
Это не полное решение, но, возможно, кто-то сталкивается с той же проблемой. Стоит проверить соединение.
Я решил это, остановив 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 был запущен не раз.
В моем случае сервер не принимал соединение с этого IP. Сервер является сервером SQL от Google Apps Engine, и вам необходимо настроить разрешенные удаленные хосты, которые могут подключаться к серверу.
Добавление (нового) хоста на страницу администратора GAE решило проблему.
У меня есть 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 Я видел, что это действительно не закрылось...
Я использую несколько соединений MySQL (подключение к различным наборам баз данных) в localhost.
Это случилось со мной после того, как я выключил свой компьютер и mysql не был должным образом выключен. После запуска машины я смог успешно подключиться к нескольким дБ-соединениям, кроме одного (я использовал это много раз перед выключением машины). В соответствии с инструкциями в этом посте я удвоил connect_timeout, но не смог подключиться к этому одному соединению с базой данных.
Я перезапустил свою машину и теперь могу успешно подключиться. Это поможет вам разблокировать себя, но было бы здорово, если бы это можно было исправить, не перезапуская машину.
Другая проблема заключается в том, что connection_timeout показался мне проблемой, связанной с задержкой, но я сразу же получил ошибку в localhost, когда в уравнении нет сети.
В моем случае это произошло, когда было много подключений к серверу MySQL (15 000 подключений), а свободной памяти было около 120 МБ. После того, как я добавил больше памяти на сервер, ошибка исчезла.
Ломал голову над этой ошибкой 3 дня. Я пытался настроить разрешения для базы данных, новых пользователей с разных IP-адресов в таблице «Пользователи», настроить адрес привязки множеством разных способов, сравнить мой файл my.cnf с известным рабочим сервером, изменения брандмауэра, изменения брандмауэра восходящего потока, хосты .allow/deny... ни один из них не работал.
Затем я посмотрел не на mysql/error.log (который оказался пустым), а на мой журнал journalctl -xe и низкий уровень, и вот, он не смог прочитать мои файлы /etc/hosts.allow и /etc/hosts.deny.
chmod 644 hosts.allowchmod 644 hosts.deny.
Теперь все лучше.
Я создал свою учетную запись только для того, чтобы добавить немного информации к этому старому вопросу, потому что нигде в Интернете я не нашел ссылок на причину моей проблемы, которую я в конце концов нашел.
(Добавление его здесь, потому что это лучший результат Google, а также при добавлении PHP в качестве поискового запроса)
В PHP 7.4, когда вы разветвляете процесс (я знаю, кто это делает ??), который имеет активное соединение с MySQL, соединение будет испорчено и выдаст ошибку OP. просто повторно инициализируйте/воссоздайте соединение в каждом разветвленном процессе после разветвления, это исправит ситуацию.
Надеюсь, это кому-нибудь поможет.
Другой возможностью может быть сброс соединения из оберток TCP (/etc/hosts.deny и /etc/hosts.allow). Просто проверьте, что поступает из телнета в порт 3306 - если это ничего, значит, что-то находится посередине, препятствуя связи.
У меня обе ошибки: в основном reading initial communication packet а также reading authorization packetодин раз. Вроде случайно, но иногда удавалось установить соединение после перезагрузки, но через некоторое время ошибка расползалась обратно.
Похоже, что отказ от Wi-Fi 5 ГГц в клиенте решил проблему. У меня это сработало (сервер всегда был подключен к 2,4 ГГц).
Я перепробовал все: от версий сервера, версий разъема odbc, настроек брандмауэра, установки некоторых обновлений Windows (а затем их удаления), некоторых ответов, размещенных здесь, и т.д... потерял все время сна на сегодня. Меня ждет супер уставший день.
В моем случае я столкнулся с этим
Lost connection to MySQL server at 'reading initial communication packet', system error: 0ошибка при подключении к кластеру RDS mysql в частной подсети с использованием приведенной ниже команды с правильными учетными данными в экземпляре ec2
Наконец, я исправил это, добавив IP-адрес VPC во входящее правило группы безопасности RDS, надеюсь, это сработает для вас.
Исправлена проблема путем измененияmy.iniфайл, по существу изменив максимально допустимый размер пакета в Mysql и изменив время ожидания до 30 секунд.
connect_timeout = 30
max_allowed_packet = 500M
Если вы получили это при использовании DevDesktop - просто перезапустите DevDesktop!