Und wieder FEHLER 1040 ...
Der technische Support erhält viele Beschwerden über diesen berüchtigten Fehler: ERROR 1040: Too many connections - zu viele Verbindungen. Das Problem liegt auf der Hand: Die Anwendung oder die Benutzer erstellen mehr Verbindungen, als der Server zulässt, max_connections die aktuelle Anzahl der Verbindungen überschreitet den Wert der Variablen max_connections .
Die Situation selbst ist ein Problem für Endbenutzer. Wenn Sie jedoch immer noch keinen Zugriff auf den Server haben, um die Ursache zu diagnostizieren und zu beheben, wird alles sehr schlecht. In der Regel müssen Sie die Instanz abschließen und neu starten, um sie wiederherzustellen.
Der Root-Benutzer kann auch keine Verbindung herstellen! Warum ?!
In einer ordnungsgemäß konfigurierten Umgebung kann ein Benutzer mit der Berechtigung SUPER auf die Instanz zugreifen und die Fehlerursache 1040 diagnostizieren, aufgrund derer nicht genügend Verbindungen bestehen. Dies ist im Handbuch beschrieben:
mysqld erlaubt max_connections + 1 Clientverbindungen. Eine zusätzliche Verbindung ist für Konten mit SUPER Berechtigungen reserviert. Wenn diese Berechtigungen Administratoren und nicht normalen Benutzern (die sie nicht benötigen) gewährt werden, kann ein Administrator, der auch über die Berechtigung PROCESS verfügt, eine Verbindung zum Server herstellen und mithilfe von SHOW PROCESSLIST Probleme diagnostizieren, selbst wenn die maximale Anzahl von Clients ohne Berechtigungen verbunden ist.
Viele Benutzer gewähren ihren Benutzern der Anwendung oder des Skripts jedoch SUPER Berechtigungen - aufgrund der Anforderungen der Anwendung (gefährlich!) Oder mangelnder Kenntnis der Konsequenzen, und dann belegt der normale Benutzer die reservierte Verbindung, und der Administrator (normalerweise root ) kann keine Verbindung herstellen.
So garantieren Sie den Zugriff auf eine Instanz
Sie können den bekannten Hack mit GDB verwenden, den Aurimas vor 100 Jahren für Fehler 1040 empfohlen hat, aber jetzt gibt es bessere Lösungen. Es stimmt, sie müssen zuerst eingeschaltet werden.
Mit Percona Server 5.5.29 und höher und MySQL 8.0.14 und höher können Sie einen anderen Port mit einer zusätzlichen Anzahl von Verbindungen konfigurieren. Die Anwendung verwendet diese Schnittstellen nicht. Sie sind nur für Datenbankadministratoren und Agenten zur Überwachung und Überprüfung des Zustands vorgesehen (siehe Hinweis unten).
Konfigurieren Sie Percona Server
Ab Percona Server 5.5.29 können Sie my.cnf einfach extra_port hinzufügen. extra_port nächsten Neustart ist der Port verfügbar und erwartet Daten auf derselben bind_address wie normale Verbindungen. Wenn Sie die Variable extra_port nicht konfigurieren, gibt es standardmäßig keinen zusätzlichen Port.
Sie können auch extra_max_connections definieren, um die Anzahl der Verbindungen anzugeben, die dieser Port verarbeiten wird. Die Standardnummer ist 1.
Zum Beispiel habe ich alle Verbindungen zum regulären Benutzerport von der Instanz genommen, in der ich extra_port und extra_max_connections in my.cnf konfiguriert my.cnf :
Ergebnis
Extra_port wurde übrigens in Percona Server 8.0.14 und höher entfernt, da admin_port mit denselben Funktionen in MySQL Community implementiert ist. Bearbeiten Sie also my.cnf beim Upgrade auf Percona Server 8.0.14 oder höher, wenn Sie extra_port bereits definiert haben.
Wie gesagt, dies erfordert MySQL 8.0.14, wo WorkLog 12138 verwendet wird .
Um die Administratorschnittstelle zu aktivieren , müssen Sie admin_addres definieren. Dies muss die einzige und eindeutige (ohne Platzhalter) IPv4-, IPv6-, IPv4-zugeordnete Adresse oder der Hostname sein, unter dem die Administratorschnittstelle auf die Übertragung von Daten wartet. Wenn diese Variable nicht definiert ist, ist die Schnittstelle nicht aktiviert.
Sie können den Port weiterhin definieren, dies ist jedoch nicht erforderlich. Standardmäßig ist dies Port 33062 . Wenn dieser Port frei ist, muss dieser Wert nicht konfiguriert werden. Wenn Sie konfigurieren, [mysqld] Sie beide Variablen in den Abschnitt [mysqld] in my.cnf .
Schließlich können Sie create_admin_listener_thread (standardmäßig deaktiviert) konfigurieren, wodurch ein separater Thread für die Verarbeitung eingehender Verbindungen erstellt wird. Dies kann in einigen Situationen nützlich sein.
Ein weiterer Unterschied besteht darin, dass in der Oracle-Dokumentation Folgendes angegeben ist:
Die Anzahl der administrativen Verbindungen ist unbegrenzt.
(Und wir haben den Standardwert 1). Ich bin mir nicht sicher, was das bedeutet, aber ich würde darauf achten, nicht versehentlich 1 Million Verbindungen herzustellen. Sie sind natürlich nicht begrenzt, verbrauchen aber dennoch Ressourcen.
Verwendung zur Überwachung und Gesundheitsprüfung
Praktischerweise können nicht nur Personen im Notfall eine zusätzliche Schnittstelle oder einen zusätzlichen Port verwenden, wenn wir max_connections erreicht max_connections . Ein Proxy- / Load-Balancer- / Service-Discovery-Überwachungssystem kann daran angeschlossen werden.
Überwachungsskripte können Daten für Diagramme abrufen, sodass Sie später herausfinden, woher so viele Verbindungen stammen. In den Skripts für die Integritätsprüfung wird über den sich verschlechternden Status des Servers berichtet, und bestimmter Code weist möglicherweise darauf hin, dass viele Verbindungen bestehen, der Server jedoch verwaltet (das heißt, er kann dies herausfinden und es ist besser, etwas länger zu warten, bis er ausfällt).
Stellen Sie sicher, dass jeweils nur eine Verbindung für Überwachung und Integritätsprüfungen installiert wird, um extra_max_connections in Percona Server nicht zu verstopfen und nicht eine Million Threads in MySQL zu erstellen. Das heißt, die Skripte sollten nicht erneut verbunden werden, wenn die vorherige Anforderung oder Verbindung zur Datenbank noch aktiv ist.
Hier ist das gleiche Beispiel, aber mit MySQL .
Für Percona Server 8.0.14 und höher ist der Prozess der gleiche wie für MySQL Community.
Hilfe! Ich muss hineingehen, aber alle Ports sind besetzt!
Wenn dies der Grund ist, warum Sie diesen Beitrag lesen, verwenden Sie einen verrückten Hack mit GDB (keine Beleidigung, Aurimas, es sieht nur riskant aus :-D) oder beenden Sie die Instanz. Glücklicherweise kann eine Instanz fast immer sauber mit SIGTERM (-15) anstelle von SIGKILL (-9) beendet werden. Der Server stoppt also sauber und die Threads können normal heruntergefahren werden. Folgen Sie einfach den Anweisungen:
1) Holen Sie sich die PID:
marcos.albe in ~/ pgrep -x mysqld; 650
2) Senden Sie SIGTERM an diese PID:
marcos.albe in ~/ kill -15 650;
3) Überprüfen Sie im Fehlerprotokoll, wie das Herunterfahren durchgeführt wird. Es wird ungefähr so aussehen:
2019-07-11T13:43:28.421244Z 0 [Note] Giving 0 client threads a chance to die gracefully 2019-07-11T13:43:28.521238Z 0 [Note] Shutting down slave threads 2019-07-11T13:43:28.521272Z 0 [Note] Forcefully disconnecting 0 remaining clients
Dies markiert den Beginn des Abschlussprozesses. Die Instanz wird abgeschlossen, wenn Sie eine ähnliche Zeile sehen:
2019-07-11T13:43:31.292836Z 0 [Note] /opt/percona_server/5.7.26/bin/mysqld: Shutdown complete