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.

Richtlinien zur Konfiguration

In diesem Abschnitt werden die in RDS Proxy verfügbaren Einstellungen beschrieben und bewährte Methoden für die Ausrichtung der Konfiguration im gesamten Anwendungsstapel beschrieben. Dies sind kombinierte Richtlinien für die Verwendung von RDS Proxy mit Amazon RDS und Amazon Aurora. RDS-specific und Aurora-specific Hinweise werden gegebenenfalls genannt.

Sofern nicht anders angegeben, beziehen sich die Begriffe „Datenbank“ oder „Ziel“ auf einen Aurora-Cluster, einen Amazon Multi-AZ RDS-DB-Cluster oder eine Amazon RDS-Instance.

Einstellungen für den RDS-Proxy

MaxConnectionsPercent

Weitere Informationen finden Sie unter MaxConnectionsPercent.

Diese Einstellung begrenzt die Anzahl der Verbindungen, die RDS Proxy mit der Zieldatenbank herstellen kann, als Prozentsatz der maximalen Anzahl von Verbindungen, die von der Datenbank zugelassen werden. Der Proxy öffnet Back-End-Verbindungen nach Bedarf, sodass die tatsächliche Anzahl von Verbindungen zu einem bestimmten Zeitpunkt unter dem konfigurierten Maximum liegen kann.

Da es sich bei der MaxConnectionsPercent Einstellung um einen Prozentsatz des Datenbankverbindungslimits handelt, folgt die Größe des Verbindungspools des Proxys automatisch der Datenbankkonfiguration. Das bedeutet, dass Sie Ihre Proxys nicht neu konfigurieren müssen, wenn Sie die Größe Ihrer Datenbankinstanzen ändern oder Konfigurationsänderungen vornehmen. Das bedeutet auch, dass Sie sich der Szenarien bewusst sein müssen, in denen sich die Datenbankeinstellungen ändern könnten, sei es implizit oder explizit:

Bewährte Methoden:

Unabhängig davon, ob Sie die MaxConnectionsPercent Standardeinstellung oder einen benutzerdefinierten Wert verwenden, sollten Sie zwischen der Anzahl der zulässigen Verbindungen und der zu Spitzenzeiten zu erwartenden maximalen Anzahl von Client-Verbindungen einen Spielraum von mindestens 30% einhalten. Beispiel:

Dieser zusätzliche Spielraum verbessert das Kundenerlebnis bei unerwarteten Arbeitslastspitzen und hilft RDS Proxy dabei, Verbindungen innerhalb seiner internen Infrastruktur für das Wärmemanagement und andere Zwecke neu zu verteilen.

Sie können einen Wert von MaxConnectionsPercent bis zu 1 festlegen, wir empfehlen jedoch je nach Instance-Typ die folgenden Mindestwerte:

MaxIdleConnectionsPercent

Weitere Informationen finden Sie unter MaxIdleConnectionsPercent.

Diese Einstellung begrenzt die Anzahl der inaktiven Datenbankverbindungen, die RDS Proxy im Verbindungspool unterhält, als Prozentsatz der maximalen Anzahl von Verbindungen, die von der Datenbank zugelassen werden. Eine Datenbankverbindung (Back-End) gilt als inaktiv, wenn fünf Minuten lang keine Aktivität auf der Verbindung stattgefunden hat. Diese Einstellung gilt für Verbindungen zwischen dem Proxy und der Back-End-Datenbank.

Beachten Sie Folgendes:

Bewährte Methoden:

Die Standardeinstellung 50 ist für die meisten Workloads geeignet und wird empfohlen. Eine Änderung der Einstellung hat folgende Auswirkungen:

Der Ressourcenverbrauch durch inaktive Verbindungen ist bei Datenbanken, die bereitgestellte Instanztypen verwenden, möglicherweise kein wesentliches Problem, aber Aurora-Datenbanken, die den Instanztyp Serverless v2 verwenden, ziehen es möglicherweise vor, den Ressourcenverbrauch im Leerlauf zu optimieren, um die Kosten zu senken.

IdleClientTimeout

Weitere Informationen finden Sie unter IdleClientTimeout.

Diese Einstellung bestimmt, wie lange eine Client-Verbindung inaktiv bleiben kann, bevor der Proxy sie schließt. Beachten Sie, dass der RDS-Proxy eine maximale Verbindungslebensdauer von 24 Stunden erzwingt, unabhängig davon, ob sich die Verbindung im Leerlauf befindet. Wenn Sie beispielsweise 30 Minuten (Standard) konfigurieren IdleClientTimeout und die Datenbank jede Minute pingen, überschreitet die Verbindung nie das Leerlauf-Timeout, sie bleibt aber nicht unbegrenzt geöffnet. RDS Proxy schließt die Verbindung nach 24 Stunden, auch wenn sie nicht als inaktiv eingestuft wird.

Die IdleClientTimeout Einstellung gilt für die Verbindung zwischen einem Client (Anwendungen oder interaktive Benutzer) und dem RDS-Proxy. Informationen zum Leerlaufverhalten von Back-End-Verbindungen zwischen dem RDS-Proxy und der Datenbank finden Sie unterMaxIdleConnectionsPercent.

Bewährte Methoden:

ConnectionBorrowTimeout

Weitere Informationen finden Sie unter ConnectionBorrowTimeout.

Wenn ein Client eine Verbindung mit dem RDS-Proxy herstellt, muss der Proxy entweder eine bestehende verfügbare Verbindung aus dem Pool ausleihen oder eine neue Datenbankverbindung öffnen. Diese Einstellung definiert, wie lange der RDS-Proxy darauf wartet, dass eine Verbindung ausgeliehen oder geöffnet wird, bevor ein Fehler zurückgegeben wird.

Beachten Sie Folgendes:

Es ist normal, dass ein Verbindungspool die maximale Kapazität unterschreitet. In diesem Fall kann die ConnectionBorrowTimeout Einstellung Null verhindern, dass der Pool wächst, da der Pool nicht warten darf, bis eine neue Verbindung geöffnet wird. Daher sollten Sie für alle Workloads ConnectionBorrowTimeout Werte ungleich Null verwenden, es sei denn, das zuvor beschriebene Verhalten wird bevorzugt.

Initialisierungsabfragen und Pinning-Filter

RDS Proxy unterstützt zusätzliche Funktionen, mit denen das Verbindungs-Pinning reduziert und somit die Effizienz des Multiplexings verbessert werden kann.

Eine Initialisierungsabfrage besteht aus einer oder mehreren Anweisungen, die jedes Mal ausgeführt werden, wenn der Proxy eine neue Back-End-Datenbankverbindung einrichtet. Wenn Ihre Clients identische Anweisungen zum Einrichten von Sitzungsparametern verwenden, können Sie diese Anweisungen in die Initialisierungsabfrage des Proxys verschieben. Dies trägt dazu bei, die Wahrscheinlichkeit eines Pinns zu verringern, und es verbessert auch die Effizienz: Eine bestimmte Back-End-Datenbankverbindung führt ihre Initialisierungsabfrage einmal während der Einrichtung aus, sie kann jedoch später von vielen Clients wiederverwendet werden. Beachten Sie, dass durch das Einfügen von SQL-Anweisungen in die Initialisierungsabfrage diese nicht aus dem Client-Verkehr herausgefiltert werden. Sie müssen diese Anweisungen dennoch aus dem Anwendungscode entfernen, damit sie das Multiplexing nicht beeinträchtigen.

Sitzungs-Pinning-Filter sind eine Konfigurationseigenschaft, die verhindert, dass der Proxy bestimmte Sitzungsstatus festlegt. Die einzige derzeit verfügbare Filteroption weist den Proxy anEXCLUDE_VARIABLE_SETS, bei der Entscheidung, ob eine Sitzung angeheftet werden soll, alle SET Anweisungen zu ignorieren. Die SET Anweisungen werden weiterhin an die Datenbank weitergegeben und können den Sitzungsstatus beeinflussen. Das bedeutet, dass diese Option nur in den folgenden Situationen sicher ist:

Um optimale Ergebnisse zu erzielen, entfernen Sie nach Möglichkeit unnötige Anweisungen aus dem Anwendungscode und verwenden Sie Filter nur, wenn Anwendungsänderungen nicht möglich sind. Auf diese Weise wird eine weniger laute und vorhersehbarere Client-Server-Umgebung erreicht, anstatt Anweisungen, die gar nicht benötigt werden, besonders zu behandeln.

Weitere Informationen finden Sie unter:

Für PostgreSQL-Verbindungen können Sie auch unterstützte Verbindungsparameter in die Startnachricht einfügen, die zwischen dem Client-Treiber und dem Proxy ausgetauscht wird. Dadurch wird das Senden separater SET Befehle vermieden, wodurch sowohl Roundtrips als auch das durch explizite Anweisungen verursachte Verbindungs-Pinning vermieden werden. SET Weitere Informationen finden Sie unter Überlegungen zum Herstellen einer Verbindung zu PostgreSQL.

Abstimmung der Anwendungs-, Proxy- und Datenbankkonfiguration

Wie im vorherigen Abschnitt beschrieben, unterstützt RDS Proxy eine Reihe von Parametern, mit denen Sie das Proxyverhalten an Ihre Anwendungsanforderungen anpassen können. Die Auswahl der richtigen Konfigurationswerte ist jedoch eine Aufgabe, die sich über alle Ebenen des Stacks erstreckt: die Anwendung, den Proxy und die Datenbank selbst. Die Einstellungen all dieser Komponenten müssen auf die folgenden Ziele ausgerichtet sein:

Versuchen Sie bei der Auswahl und Optimierung von Einstellungen in einer mehrschichtigen Umgebung, die Konfigurationswerte so aufeinander abzustimmen, dass die Grenzwerte und Timeouts auf einer niedrigeren Ebene den entsprechenden Grenzwerten und Timeouts auf einer höheren Ebene entsprechen oder diese überschreiten. Mit anderen Worten: Behandeln Sie die Einstellungen einer Ebene wie eine Hülle, die in die nächste Konfigurationshülle weiter unten im Stapel passt.

Gehen Sie beispielsweise davon aus, dass sich Ihre Anwendung auf der obersten Ebene befindet, der Proxy auf der mittleren Ebene und die Datenbank auf der unteren Ebene. Wenn die Timeouts und Grenzwerte auf Proxyebene niedriger sind als die Grenzwerte auf Anwendungsebene, haben Proxylimits Vorrang vor Anwendungslimits. Die Anwendung kann ihre Einstellungen nicht anwenden und es treten Verhaltensweisen auf, die nicht durch ihre eigene Konfiguration erklärt werden können.

Betrachten Sie die IdleClientTimeout Proxyeinstellung als Beispiel. Wenn Ihre Anwendungstreiber oder Client-Pools ihre eigenen Leerlauf-Timeouts erzwingen, ist das Leerlauf-Timeout des Proxys zusätzlich zu den Anwendungseinstellungen ein Sicherheitsnetz. Das bedeutet, dass der Wert mindestens allen Leerlaufzeitüberschreitungen auf Anwendungsebene entsprechen IdleClientTimeout muss, um Verwirrung zu vermeiden:

Dieselbe Logik gilt für andere Einstellungen wie Verbindungslimits: Die Einstellungen jeder Ebene sollten innerhalb der durch die Konfiguration der nächsten Ebene definierten Envelope passen.

Um optimale Ergebnisse zu erzielen, sollten die Konfigurationseinstellungen einen gewissen Abstand zwischen einer Ebene und der nächsten vorsehen. Sie können beispielsweise das Proxy-Timeout um einige Sekunden länger als das Anwendungs-Timeout festlegen, um sporadische Fehler aufgrund von Zeitverschiebungen zu client/server vermeiden, oder falls der Client zusätzliche Zeit benötigt, um die Verbindung ordnungsgemäß zu schließen.

Mit anderen Worten, richten Sie Ihre Einstellungen wie folgt aus:

client timeout < proxy timeout < database timeout

Anstatt das zu tun:

client timeout = proxy timeout = database timeout

Und vermeide das:

client timeout > proxy timeout > database timeout

Datenbankkonfiguration

Verbindungsgrenzen

RDS Proxy verwendet MaxConnectionsPercent diese Einstellung, um die maximale Größe seines Verbindungspools zu bestimmen, was bedeutet, dass die Größe des Verbindungspools des Proxys relativ zum Verbindungslimit der Datenbank ist. Wenn Sie das Verbindungslimit der Datenbank ändern, folgt die Poolgröße des Proxys automatisch. Wenn Sie möchten, dass die Datenbank einen Teil des Verbindungslimits für Nicht-Proxybenutzer reserviert, sollten Sie dazu die MaxConnectionsPercent Einstellung im Proxy verringern, anstatt das Datenbanklimit zu erhöhen.

Der RDS-Proxy macht eine korrekte Konfiguration der Datenbankverbindungslimits nicht überflüssig. Eine einzelne Proxyverbindung ist nicht von Natur aus leichter als eine einzelne direkte Client-Verbindung. Erhöhen Sie daher die Datenbanklimits nicht, nur weil Sie einen Proxy verwenden. Ein Proxy reduziert nicht den Arbeitsaufwand, den die Datenbank zur Bearbeitung von Abfragen ausführen muss, aber er hilft der Datenbank, dieselbe Arbeitslast mit weniger Verbindungen zu bewältigen.

Timeouts im Leerlauf

Datenbanken können ihre eigenen Leerlauf-Timeouts erzwingen, indem sie beispielsweise die interactive_timeout Einstellungen wait_timeout und in MySQL oder die idle_in_transaction_session_timeout Einstellungen transaction_timeout und in PostgreSQL verwenden. Es ist unwahrscheinlich, dass die Standardwerte für diese Einstellungen die Proxykonfiguration beeinträchtigen. Wenn Sie jedoch benutzerdefinierte Timeouts auf Datenbankebene verwenden, stellen Sie sicher, dass diese mindestens so lang sind wie die entsprechenden Proxy-Timeouts, da sonst Verbindungsfehler aufgrund vorzeitiger Timeouts auftreten.

Dieselbe Logik gilt für Datenbankumgebungen, die Verbindungskiller verwenden. Dabei handelt es sich um Skripten oder Prozesse, die den Sitzungsstatus überwachen und Verbindungen anhand bestimmter Kriterien aktiv beenden. Wenn Ihre Umgebung solche Techniken verwendet, stellen Sie sicher, dass die Logik des Verbindungsabbruchs mit den Proxyeinstellungen übereinstimmt.

Datenbanken, die ihre gesamte Arbeitslast über den Proxy abwickeln, können in der Regel von der Proxykonfiguration für Leerlaufzeitüberschreitungen abhängen und die Einstellungen auf Datenbankebene auf ihren Standardwerten belassen.

Konfiguration der Anwendung

Sitzungsstatus verwalten

Viele Datenbanktreiber, Anwendungsframeworks und ORM-Tools (Object-Relational Mapping) verwenden Sitzungsvariablen oder SET Anweisungen, um Verbindungen einzurichten, bevor Abfragedatenverkehr gesendet wird. Die Verwendung von Verbindungs- und Transaktionsinitialisierungsanweisungen ist möglicherweise nicht offensichtlich, wenn man nur den Anwendungscode betrachtet, und es kann mehrere Abstraktionsebenen zwischen der Datenbank selbst und den SQL-Anweisungen und der Anwendungslogik geben. Sie können die erweiterte Protokollierungsfunktion von RDS Proxy verwenden, um die Gründe für das Verbindungs-Pinning aufzuzeichnen, und Datenbankabfrageprotokolle können weitere Informationen zu allen Anweisungen liefern, die über Ihre Datenbankverbindungen gesendet wurden.

Bedenken Sie die folgenden bewährten Methoden:

Überprüfung der Lebendigkeit

Wenn Ihre Anwendung Verbindungspooling oder erweiterte Treiber verwendet, suchen Sie nach Konfigurationen, die sich auf Verfügbarkeitsprüfungen beziehen, z. B. Protokoll-Pings, Anweisungen zur Integritätsprüfung oder Keep-Alive-Abfragen. Der RDS-Proxy behandelt alle Client-Anfragen gleich. Auch wenn eine SELECT 1; Abfrage oder COM_PING Anforderung aus Sicht der Anwendung ein No-Op ist, verhindert er, dass der Proxy Timeouts bei inaktiven Clients erzwingt und die Größe des Verbindungspools entsprechend verwaltet. MaxIdleConnectionsPercent

In den meisten Fällen kann es sinnvoll sein, die clientseitigen Verfügbarkeitsprüfungen zu deaktivieren, um das Protokollrauschen zu reduzieren und RDS Proxy bei der Verwaltung inaktiver Verbindungen zu unterstützen. Es gibt Ausnahmefälle, in denen Sie diese Integritätsprüfungen trotzdem durchführen möchten:

Erwägen Sie, die Verfügbarkeitsprüfungen auf der Anwendungsseite zu deaktivieren, oder führen Sie sie nur für die spezifischen Verbindungen durch, bei denen Sie verhindern möchten, dass es zu einem Timeout kommt.

Nachverfolgung des Sitzungsstatus

Einige MySQL-Datenbanktreiber, wie der MariaDB-Treiber, verwenden session_track_* Variablen, um die Verfolgung des Sitzungsstatus zu ermöglichen. Wenn diese Funktion aktiviert ist, nimmt der Server bei jeder Änderung des Sitzungsstatus, die der Server verfolgen kann, die Informationen zur Statusänderung in seine Antwortpakete auf. Dadurch kann der Treiber vom Server über den Sitzungsstatus informiert werden.

Diese Art der Sitzungsstatusverfolgung kann sinnvoll sein, wenn der Client direkt mit dem Server interagiert und seine eigenen Sitzungsverwaltungsfunktionen implementiert, z. B. die Sitzungsmigration in Umgebungen mit mehreren Servern. RDS Proxy implementiert seine eigenen Zustandsverfolgungsmechanismen und verwendet nicht die durch session_track_* Variablen aktivierten Informationen. Das Setzen dieser Variablen führt jedoch zu Session-Pinning.

Wenn Ihr Datenbanktreiber diese Variablen festlegt, können Sie nach Möglichkeiten suchen, die Tracking-Funktionalität im Treiber zu deaktivieren, zu einem anderen Treiber zu wechseln oder Sitzungs-Pinning-Filter zu verwenden, um die Anweisungen zu ignorieren, sofern dies sicher ist. Weitere Details finden Sie unter Initialisierungsabfragen und Pinning-Filter.