Beheben von Verbindungsprobleme in Azure Database for MySQL – Flexibler Server
Die MySQL Community Edition verwaltet Verbindungen mit einem Thread pro Verbindung. Folglich erhält jede Benutzerverbindung im mysqld-Prozess einen dedizierten Betriebssystemthread.
Bei dieser Art der Verbindungsbehandlung gibt es potenzielle Probleme. Beispielsweise ist bei einer großen Anzahl von Benutzerverbindungen die Arbeitsspeichernutzung relativ hoch, selbst wenn es sich um Verbindungen im Leerlauf handelt. Außerdem kommt es bei Tausenden von Benutzerverbindungen zu mehr internen Serverkonflikten und einem Mehraufwand beim Kontextwechsel.
Diagnostizieren von häufigen Verbindungsfehlern
Wenn bei Ihrer Instanz von Azure Database for MySQL – Flexibler Server Verbindungsprobleme auftreten, denken Sie daran, dass Probleme auf jeder der drei beteiligten Ebenen auftreten können: auf dem Clientgerät, im Netzwerk oder in Ihrer Instanz von Azure Database for MySQL – Flexibler Server.
Berücksichtigen Sie daher beim Diagnostizieren von Verbindungsfehlern immer alle Details der folgenden Elemente:
- Client, einschließlich:
- Konfiguration (lokal, Azure-VM usw. oder DBA-Computer).
- Betriebssystem:
- Software und Versionen.
- Verbindungszeichenfolge und alle enthaltenen Parameter.
- Netzwerktopologie (dieselbe Region/VZ? Firewallregeln? Routing).
- Verbindungspool (Parameter und Konfiguration), sofern einer verwendet wird.
Es ist auch wichtig festzustellen, ob das Datenbankverbindungsproblem ein einzelnes Clientgerät oder mehrere Clientgeräte betrifft. Wenn sich die Fehler nur auf einen von mehreren Clients auswirken, ist es wahrscheinlich, dass das Problem bei diesem Client liegt. Wenn jedoch bei allen Clients derselbe Fehler auftritt, ist es wahrscheinlicher, dass das Problem auf der Seite des Datenbankservers oder in der Netztechnologie dazwischen liegt.
Berücksichtigen Sie unbedingt auch die Möglichkeit einer Workloadüberladung, insbesondere, wenn eine Anwendung in sehr kurzer Zeit eine sehr große Anzahl von Verbindungen öffnet. Sie können Metriken wie „Verbindungen insgesamt“, „Aktive Verbindungen“ und „Abgebrochene Verbindungen“ verwenden, um dies zu untersuchen.
Wenn Sie eine Verbindung von einem Clientgerät oder einer Anwendung herstellen, erfolgt in MySQL zuerst der wichtige Aufruf der Funktion „getaddrinfo“, die die DNS-Übersetzung vom angegebenen Endpunkt in eine IP-Adresse vornimmt. Wenn das Abrufen der Adresse fehlschlägt, wird in MySQL eine Fehlermeldung angezeigt, wobei am Ende die Zahl in Klammern (11, 110 usw.) angegeben ist, wie z. B. „ERROR 2005 (HY000): Unknown MySQL server host 'mysql-example.mysql.database.azure.com' (11)“.
Clientseitige Fehlercodes für ERROR 2005
In der folgenden Tabelle finden Sie Kurzverweise zu einigen clientseitigen Fehlercodes für ERROR 2005.
ERROR 2005-Code | Hinweise |
---|---|
(11) „EAI_SYSTEM – System error“ | Es liegt ein Fehler bei der DNS-Auflösung auf der Clientseite vor. Kein Problem von Azure Database for MySQL – Flexibler Server. Verwenden Sie auf dem Client den Befehl „dig/nslookup“, um das Problem zu beheben. |
(110) „ETIMEDOUT (Connection timed out)“ | Beim Herstellen einer Verbindung mit dem DNS-Server des Clients ist ein Timeout aufgetreten. Kein Problem von Azure Database for MySQL – Flexibler Server. Verwenden Sie auf dem Client den Befehl „dig/nslookup“, um das Problem zu beheben. |
(0) „name unknown“ | Der angegebene Name konnte nicht von DNS aufgelöst werden. Überprüfen Sie die Eingabe auf dem Client. Dies ist wahrscheinlich kein Problem mit Azure Database for MySQL – Flexibler Server. |
Der zweite Aufruf in MySQL erfolgt über eine Socketverbindung. Wenn der Vorgang fehlschlägt, wird eine Fehlermeldung angezeigt, wobei am Ende die Zahl in Klammern (99, 110, 111, 113 usw.) angegeben ist, wie z. B. „ERROR 2003 (HY000): Can't connect to Azure Database for MySQL flexible server on 'mysql-example.mysql.database.azure.com' (111)“ (FEHLER 2003 (HY000): Verbindung mit Azure DB for MySQL – Flexibler Server kann auf „mysql-example.mysql.database.azure.com” nicht hergestellt werden (111)).
Clientseitige Fehlercodes für ERROR 2003
In der folgenden Tabelle finden Sie Kurzverweise zu einigen clientseitigen Fehlercodes für ERROR 2003.
ERROR 2003-Code | Hinweise |
---|---|
(99) „EADDRNOTAVAIL (Cannot assign requested address)“ | Dieser Fehler wird nicht von Azure Database for MySQL – Flexibler Server verursacht, sondern liegt auf der Clientseite. |
(110) „ETIMEDOUT (Connection timed out)“ | Beim Herstellen einer Verbindung mit der angegebenen IP-Adresse ist eine Zeitüberschreitung aufgetreten. Wahrscheinlich liegt ein Sicherheitsproblem (Firewallregeln) oder ein Netzwerkproblem (Routing) vor. In der Regel ist dies kein Problem mit Azure Database for MySQL – Flexibler Server. Verwenden Sie auf dem Clientgerät den Befehl nc/telnet/TCPtraceroute , um das Problem zu beheben. |
(111) „ECONNREFUSED (Connection refused)“ | Die Pakete haben zwar den Zielserver erreicht, aber der Server hat die Verbindung abgelehnt. Möglicherweise wurde versucht, eine Verbindung mit dem falschen Server oder dem falschen Port herzustellen. Dies kann auch damit zusammenhängen, dass der Zieldienst (Azure Database for MySQL – Flexibler Server) ausgefallen ist, nach einem Failover wiederhergestellt wird oder eine Wiederherstellung nach einem Systemabsturz durchläuft und noch keine Verbindungen akzeptiert. Dieses Problem kann aufseiten des Clients oder aufseiten des Servers liegen. Verwenden Sie auf dem Clientgerät den Befehl nc/telnet/TCPtraceroute , um das Problem zu beheben. |
(113) „EHOSTUNREACH (Host unreachable)“ | Die Routingtabelle des Clientgeräts enthält keinen Pfad zum Netzwerk, in dem sich der Datenbankserver befindet. Überprüfen Sie die Netzwerkkonfiguration des Clientgeräts. |
Sonstige Fehlercodes
In der folgenden Tabelle finden Sie Kurzhinweise zu einigen anderen Fehlercodes im Zusammenhang mit Problemen, die nach dem erfolgreichen Herstellen der Netzwerkverbindung mit dem Datenbankserver auftreten.
Fehlercode | Hinweise |
---|---|
ERROR 2013: Lost connection to MySQL server | Die Verbindung wurde zwar hergestellt, aber danach getrennt. Dies kann passieren, wenn versucht wird, eine Verbindung mit einem anderen System als MySQL herzustellen (beispielsweise wenn versucht wird, mit einem MySQL-Client eine Verbindung mit SSH auf Port 22 herzustellen). Dies kann auch passieren, wenn der Administrator die Sitzung beendet. Dies kann auch passieren, wenn die Datenbank die Sitzung aufgrund einer Zeitüberschreitung beendet. Oder es handelt sich um Probleme mit dem Datenbankserver, nachdem die Verbindung hergestellt wurde. Der Fehler kann jederzeit während der Lebensdauer der Clientverbindung auftreten. Dies kann ein Hinweis darauf sein, dass in der Datenbank ein schwerwiegendes Problem aufgetreten ist. |
ERROR 1040: Too many connections | Die Anzahl der verbundenen Datenbankclients hat bereits die konfigurierte maximale Anzahl erreicht. Sie müssen herausfinden, warum so viele Verbindungen mit der Datenbank hergestellt werden. |
ERROR 1045: Access denied for user | Der Client hat einen falschen Benutzernamen oder ein falsches Kennwort angegeben, sodass die Datenbank den Zugriff verweigert hat. |
ERROR 2006: MySQL server has gone away | Dieser Fehler ist mit dem Eintrag ERROR 2013: Lost connection to MySQL server in der vorherigen Tabelle vergleichbar. |
ERROR 1317: Query execution was interrupted | Fehler, der auf dem Client auftritt, wenn der primäre Benutzer die Abfrage und nicht die Verbindung beendet. |
ERROR 1129: Host '1.2.3.4' is blocked because of many connection errors | Fehlermeldung „Unblock with 'mysqladmin flush-hosts'“: Alle Clients eines Computers werden blockiert, wenn ein Client dieses Computers mehrmals versucht, mit dem falschen Protokoll eine Verbindung mit MySQL herzustellen (Telnetting auf den MySQL-Port ist ein Beispiel). Wie die Fehlermeldung besagt, muss der Administratorbenutzer der Datenbank den Befehl FLUSH HOSTS; ausführen, um das Problem zu beheben. |
Hinweis
Weitere Informationen zu Verbindungsfehlern finden Sie im Blogbeitrag Untersuchen von Verbindungsproblemen mit Database for MySQL – Flexibler Server.