Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Verwalten von Verbindungen
Wenn die Nachfrage nach Ihrer Anwendung steigt, steigt auch der Frontend-Verkehr. In einem typischen Szenario richten Sie die automatische Skalierung auf Anwendungsebene ein, um einen solchen Anstieg an eingehendem Datenverkehr zu bewältigen. Infolgedessen beginnt die Anwendungsebene automatisch zu skalieren und es werden mehr Anwendungsserver (Instances) hinzugefügt, um dem Anstieg des Datenverkehrs gerecht zu werden. Da alle Anwendungsserver über vorkonfigurierte Einstellungen für den Datenbank-Verbindungspool verfügen, nimmt die Anzahl der eingehenden Verbindungen zur Datenbank proportional zu den neu bereitgestellten Instances zu.
Beispielsweise würden 20 Anwendungsserver, die mit jeweils 200 Datenbankverbindungen konfiguriert sind, insgesamt 4 000 Datenbankverbindungen öffnen. Wenn der Anwendungspool auf bis zu 200 Instances skaliert wird (z. B. zu Spitzenzeiten), wird die Gesamtzahl der Verbindungen 40 000 erreichen. Bei einem typischen Workload befinden sich die meisten dieser Verbindungen wahrscheinlich im Leerlauf. Der Anstieg der Verbindungen könnte jedoch die Skalierbarkeit Ihrer Datenbank von Amazon-Aurora-MySQL-kompatible Edition einschränken. Das liegt daran, dass selbst Verbindungen im Leerlauf Arbeitsspeicher und andere Serverressourcen wie Dateideskriptoren verbrauchen. Aurora MySQL-kompatibel benötigt in der Regel weniger Speicher als die MySQL Community Edition, um die gleiche Anzahl von Verbindungen aufrechtzuerhalten. Der Speicherverbrauch für inaktive Verbindungen ist jedoch immer noch nicht Null.
Konfigurationsvariablen
Sie können die Anzahl der zulässigen eingehenden Verbindungen zu Ihrer Datenbank mit zwei wichtigen Serverkonfigurationsvariablen steuern: max_connections und max_connect_errors.
Konfigurationsvariable max_connections
Die Konfigurationsvariable max_connections begrenzt die Anzahl der Datenbankverbindungen für jede MySQL-Instance. Es empfiehlt sich, sie etwas höher als die maximale Anzahl von Verbindungen festzulegen, die Sie voraussichtlich auf jeder Datenbank-Instance öffnen werden.
Wenn Sie auch performance_schema aktiviert haben, seien Sie besonders vorsichtig mit der max_connections-Einstellung. Die Größe der Speicherstrukturen des Performance-Schemas wird automatisch auf der Grundlage von Serverkonfigurationsvariablen festgelegt, inklusive max_connections. Je höher Sie die Variable setzen, desto mehr Speicher verwendet Performance Schema. In extremen Fällen kann dies zu out-of-memory Problemen bei kleineren Instance-Typen führen. Beachten Sie, dass durch die Aktivierung von Performance Insights automatisch das Performance Schema aktiviert wird.
Konfigurationsvariable max_connect_errors
Die Konfigurationsvariable max_connect_errors bestimmt, wie viele aufeinanderfolgende unterbrochene Verbindungsanfragen von einem bestimmten Client-Host aus zulässig sind. Wenn der Client-Host die angegebene Anzahl aufeinanderfolgender fehlgeschlagener Verbindungsversuche überschreitet, blockiert der Server ihn. Weitere Verbindungsversuche von diesem Client führen zu einem Fehler.
Host 'host_name' is blocked because of many connection errors. Unblock with
'mysqladmin flush-hosts'
Wenn bei Ihnen die Fehlermeldung „Host ist blockiert“ auftritt, vermeiden Sie es, den Wert der max_connect_errors Variablen zu erhöhen. Untersuchen Sie stattdessen die Diagnosezähler des Servers in der aborted_connects-Zustandvariable und die host_cach-Tabelle. Verwenden Sie die gesammelten Informationen, um Clients zu identifizieren und zu reparieren, bei denen Verbindungsprobleme auftreten. Beachten Sie auch, dass dieser Parameter keine Wirkung hat, wenn skip_name_resolve auf 1 eingestellt ist (Standard).
Einzelheiten zu den folgenden Themen finden Sie im MySQL-Referenzhandbuch:
Verbindungspooling implementieren
Durch ein Skalierungsereignis können weitere Anwendungsserver hinzugefügt werden, was wiederum dazu führen kann, dass der DB-Server die Anzahl der voll ausgelasteten aktiven Verbindungen überschreitet. Das Hinzufügen eines Verbindungspools oder einer Proxyschicht zwischen den Anwendungsservern und der Datenbank wirkt wie ein Trichter und reduziert die Gesamtzahl der Verbindungen in der Datenbank. Der Hauptzweck eines Proxys ist die Wiederverwendung von Datenbankverbindungen durch Multiplexing.
Auf der einen Seite stellt der Proxy über eine kontrollierte Anzahl von Verbindungen eine Verbindung zur Datenbank her. Auf der anderen Seite akzeptiert der Proxy Anwendungsverbindungen. Er bietet auch zusätzliche Features wie Abfrage-Caching, Verbindungspufferung, Umschreiben und Routing von Abfragen sowie Lastenausgleich. Die Verbindungspoolschicht muss so konfiguriert werden, dass die maximale Anzahl von Verbindungen zur Datenbank unter der vollständig geladenen Anzahl bleibt. Amazon-RDS-Proxy
Sie können sich auch die folgenden Drittanbieter-Proxys ansehen, die mit Aurora-MySQL-kompatible verwendet werden können:
Vermeiden Sie Verbindungsstürme
Überlegen Sie, wie sich Ihr Verbindungspool verhält, wenn eine Datenbank überlastet ist oder ein Replikat zu weit hinter dem Primärknoten zurückfällt. Achten Sie bei der Konfiguration Ihres Proxyservers oder Ihrer Verbindungspools darauf, dass Sie nicht den gesamten Verbindungspool aufgrund langsamer Datenbankantworten (verursacht durch zugrundeliegende Hardware- oder Speicherprobleme oder Datenbankressourcenbeschränkungen) zurücksetzen.
Wenn Sie plötzlich Hunderte von Verbindungen starten, entsteht ein Verbindungssturm, weil eine große Anzahl von Anfragen für neue Verbindungen zur Datenbank gleichzeitig initiiert wird. Der Sturm ist ressourcenintensiv. Das Erstellen einer neuen Datenbankverbindung in MySQL ist ein teurer Vorgang, da das Backend mehrere Netzwerkpakete für den ersten Handshake austauscht, einen neuen Prozess startet, Speicher zuweist, die Authentifizierung abwickelt und so weiter. Wenn in einem kurzen Zeitraum eine große Anzahl von Anfragen eingeht, kann es so aussehen, als ob die Datenbank nicht reagiert.
MySQL verfügt über einen Mechanismus zum Schutz vor einem solchen Anstieg der Verbindungsanfragen. Die Variable back_log kann auf die Anzahl der Anfragen gesetzt werden, die während einer kurzen Zeit gestapelt werden können, bevor MySQL vorübergehend aufhört, neue Anfragen zu beantworten. Der Wert wird durch einen Thread zur Verbindungsverwaltung erzwungen, der selbst durch einen Verbindungssturm überfordert werden könnte. Weitere Informationen finden Sie im MySQL-Referenzhandbuch
Wenn Ihre Verbindung so konfiguriert ist, dass sie zurückgesetzt wird, wenn die Datenbank langsam ist, werden Sie den Zyklus immer wieder neu initiieren. Wenn Sie zu bestimmten Tageszeiten (z. B. wenn die Börse öffnet) mit einem plötzlichen Anstieg des Datenbankverkehrs rechnen, sollten Sie Ihren Verbindungspool entsprechend vorwärmen, sodass Sie nicht versuchen, viele Verbindungen gleichzeitig zu öffnen, wenn eine hohe Datenverkehrslast aufkommt.
