ERROR 2013 (HY000): Verlorene Verbindung zum MySQL-Server auf 'Leseberechtigung Paket', Systemfehler: 0

Question

Ich erhalte die folgenden Fehler

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

wenn sie versuche, meinen MySQL-Server zu verbinden.

Was ich tue:

• Ich habe Master - Slave-Replikation in MySQL, die funktioniert und nur Lastausgleichsfunktionen mit F5 hinzugefügt.
• Ich habe die F5 nach ihrem Standort konfiguriert.

Aber wenn ich versuche, auf meinen MySQL-Server mit dem IP zu verbinden, dass die F5 konfiguriert wurde mit I

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

Irgendwelche Ideen?

---

-Update auf meinem Fortschritt: ZERO
- Ich bin der gleichen Fehler ich in das Verzeichnis/var keine Einträge/log/secure, als ob jemand Form zu authentifizieren versuchen würde, die IP kommen, wo ich hatte meinen Load-Balance-Server erstellt.
Keine enties im mysql Fehlerprotokoll.
Der Befehl - gibt nichts

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

Ich habe meine my.cnf Datei bereits geändert und die

[mysqld] 
skip-name-resolve 

Alterd die connect_timeout bis 10.
So fügen Sie es scheint, ich habe keine Antwort für den Server erhalten ich habe auf meinem F5 erstellt
ich endlich den F5 Admin habe mir überzeugt, das Protokoll für den F5-Server zu übergeben, und ich habe alles, was ich bilden muß es exctraced. Hier
ist die Ausgabe:

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) 

ich die ip für die Sicherheit willen ersetzt haben!

nur als Statist - und ich denke, ist hier das Problem - meine MySQL-Version ist 5.1.69-log Thx Alle

Answer 1

From documentation:

More rarely, it can happen when the client is attempting the initial connection to the server. In this case, if your connect_timeout value is set to only a few seconds, you may be able to resolve the problem by increasing it to ten seconds, perhaps more if you have a very long distance or slow connection. You can determine whether you are experiencing this more uncommon cause by using SHOW STATUS LIKE 'aborted_connections'. It will increase by one for each initial connection attempt that the server aborts. You may see “reading authorization packet” as part of the error message; if so, that also suggests that this is the solution that you need.

Versuchen connect_timeout in Ihrer my.cnf Datei zu erhöhen

Ein anderer Stil:

MySQL: Verlorene Verbindung zum MySQL-Server an 'Init lesen ial Kommunikationspaket‘

1. Irgendwann war es unmöglich, für Remote-Clients zu der MySQL-Server zu verbinden.

2. Der Client (einige Anwendung auf einer Windows-Plattform) gab eine vage Beschreibung wie Connection unexpectedly terminated.

3. Wenn die Ferne mit dem MySQL-Client-Anmeldung in dem folgenden Fehler erschienen:

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

Auf FreeBSD dies geschieht, weil es keine Übereinstimmung in /etc/hosts.allow. Hinzufügen die folgende Zeile vor der Zeile gefunden wurde sagen ALL:ALL behebt dieses:

mysqld: ALL: allow 

On Nicht-FreeBSD Unix-Systemen ist es lohnt sich, die Dateien /etc/hosts.allow und /etc/hosts.deny. zu überprüfen Wenn Sie Verbindungen beschränken, stellen Sie sicher, dass diese Linie in /etc/hosts.allow ist:

mysqld: ALL 

oder prüfen Sie, ob der Wirt in /etc/hosts.deny.

aufgeführt wird in Arch Linux, kann eine ähnliche Linie /etc/hosts.allow hinzugefügt:

mysqld: ALL 

Answer 2

Diese in der Regel durch eine abgebrochene connect verursacht wird. Sie können dies überprüfen, indem Sie die Statusprüfung:

mysql> SHOW GLOBAL STATUS LIKE 'Aborted_connects'; 

Wenn diese Zähler zu erhöhen halten, wie Sie die verlorenen Verbindungen bekommen, das ist ein Zeichen, die Sie während connect ein Problem haben.

Ein Mittel, das in vielen Fällen zu arbeiten scheint, ist das Timeout zu erhöhen.Ein vorgeschlagene Wert ist 10 Sekunden:

mysql> SET GLOBAL connect_timeout = 10; 

Eine weitere häufige Ursache von connect Timeouts ist die Umkehrung-DNS-Lookup, die notwendig ist, wenn Kunden zu authentifizieren. Es wird empfohlen, MySQL mit der Konfigurationsvariable in my.cnf auszuführen:

[mysqld] 
skip-name-resolve 

Dies bedeutet, dass Ihre GRANT Aussagen, die auf IP-Adresse werden müssen, anstatt den Hostnamen. auch diesen Bericht von 2012 im f5.com Website gefunden

---

I (jetzt durch Login geschützt, aber ich habe es through Google cache)

It is likely the proxy will not work unless you are running BIG-IP 11.1 and MySQL 5.1, which were the versions I tested against. The MySQL protocol has a habit of changing.

Ich schlage vor, Sie F5 Support kontaktieren und bestätigen, dass Sie verwenden eine unterstützte Kombination von Versionen.

Answer 3

eine weitere Möglichkeit Verbindung zurückgesetzt von dem TCP-Wrapper sein kann (/etc/hosts.deny und /etc/hosts.allow). Überprüfen Sie einfach, was vom Telnet zu Port 3306 kommt - wenn es nichts ist, dann ist etwas in der Mitte, das die Kommunikation verhindert.

Answer 4

Mein Fall war, dass der Server die Verbindung von dieser IP nicht akzeptierte. Der Server ist ein SQL-Server von Google Apps Engine. Sie müssen zulässige Remote-Hosts konfigurieren, die eine Verbindung zum Server herstellen können.

Das Hinzufügen des (neuen) Hosts zur GAE-Verwaltungsseite hat das Problem gelöst.

Answer 5

Ich benutze mehrere mysql Verbindungen (Verbindung zu verschiedenen Gruppen von Datenbanken) in localhost.

Das ist mir passiert, nachdem ich meinen Computer heruntergefahren und mysql nicht ordnungsgemäß heruntergefahren wurde. Nach dem Start meiner Maschine konnte ich erfolgreich eine Verbindung zu mehreren db-Verbindungen herstellen, bis auf eine (ich habe das vor dem Herunterfahren meiner Maschine oft benutzt). Gemäß den Anweisungen in diesen Posts verdoppelte ich connect_timeout, aber ich konnte keine Verbindung zu dieser einen Datenbankverbindung herstellen.

Ich habe meinen Rechner neu gestartet und kann jetzt erfolgreich verbinden. Dies wird Ihnen helfen, sich selbst zu entsperren, aber es wäre großartig, wenn es repariert werden kann, ohne den Rechner neu zu starten.

Ein weiteres Problem ist: connection_timeout schien zu mir Problem zu verzögern, aber ich bekam den Fehler sofort in localhost, wenn es kein Netzwerk in der Gleichung gibt.

Answer 6

Ich habe viel mit diesem Fehler gekämpft. Versuchte jede einzelne Antwort, die ich im Internet fand.

Am Ende habe ich meinen Computer an den Hotspot meines Handys angeschlossen und alles hat funktioniert. Ich stellte fest, dass das Internet meines Unternehmens die Verbindung mit MySQL blockierte.

Dies ist keine vollständige Lösung, aber vielleicht hat jemand das selbe Problem. Es lohnt sich, die Verbindung zu überprüfen.

Answer 7

In meinem Fall passiert es, wenn es eine Menge Verbindung zum MySQL-Server (15.000 Verbindungen) gab und der freie Speicher etwa 120M war.Nachdem ich dem Server mehr Speicher hinzugefügt hatte, war der Fehler behoben.

Answer 8

Ich löste das, indem ich mysql mehrmals beendete.

$ 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 

Alles gut von hier. Ich vermute, dass mysql mehr als einmal gestartet wurde.