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.
Überlegungen zu Anwendung und Arbeitslast
Themen
Multi-tenant und Umgebungen mit mehreren Benutzern
Wenn es um Skalierbarkeit und Verbesserung der Verbindungsverwaltung geht, hängen die Vorteile der Verwendung von RDS Proxy von seiner Fähigkeit ab, Verbindungspooling und in viel größerem Umfang Verbindungsmultiplexing durchzuführen. Verbindungspooling reduziert den Aufwand, der mit dem Öffnen und Schließen von Verbindungen verbunden ist. Verbindungsmultiplexing ermöglicht es dem Proxy, eine Back-End-Datenbankverbindung nach einer Transaktion wiederzuverwenden. Weitere Informationen finden Sie unter Konzepte und Terminologie zu RDS-Proxy.
Wenn eine Verbindung nicht gemultiplext werden kann, greift der Proxy auf ein Verhalten zurück, das als Verbindungs-Pinning bezeichnet wird. Pinning ist eine Situation, in der ein Client gezwungen ist, für seine gesamte Sitzung dieselbe zugrunde liegende Proxyverbindung zu verwenden. Die Proxyverbindung ist für diesen einen Client reserviert, sodass sie nicht für die Wiederverwendung durch andere Clients verfügbar ist. Mit anderen Worten, beim Pinning wird eine exklusive 1:1 -Zuordnung zwischen einer Client-Proxy-Verbindung und einer Proxy-Datenbankverbindung hergestellt. Die Vermeidung von Pinning ist in allen Szenarien wichtig, in denen RDS Proxy hauptsächlich aus Gründen der Skalierbarkeit und Effizienz verwendet wird. Informationen zum aktuellen Fixierungsverhalten finden Sie unter Vermeiden von Pinning beim RDS-Proxy.
In der Regel können Verbindungen gemultiplext werden, wenn sie einen identischen Status haben. Verbindungen können nicht gemultiplext werden, wenn sie benutzerdefinierte sitzungsspezifische Statusinformationen enthalten. Einer der Aspekte, die den Sitzungsstatus definieren, ist der Datenbankbenutzername, der einer Verbindung zugeordnet ist. Wenn Sie sich als „User_A“ mit dem Proxy verbinden, muss der Proxy auch eine Back-End-Datenbankverbindung als „User_A“ öffnen. Der Proxy kann diese Back-End-Verbindung potenziell für andere Clients bündeln und wiederverwenden, die sich als „User_A“ anmelden, aber nicht für Clients, die einen anderen Benutzernamen verwenden.
Dieses Verhalten kann die Effizienz von Pooling und Multiplexing in Mehrbenutzerumgebungen mit einer großen Anzahl einzigartiger Datenbankkonten erheblich reduzieren. Dies gilt insbesondere für Architekturen, die Mehrmandantenfähigkeit auf Datenbank- oder Schemaebene verwenden. Wenn die Datenbank tausend Schemas enthält (eines pro Mandant) und jeder Mandant mit einem anderen Benutzernamen eine Verbindung zur Datenbank herstellt, wird der Verbindungspool in benutzerspezifische Mikropools fragmentiert, was die Gesamteffizienz beeinträchtigt.
Darüber hinaus können spezifische Aspekte der Datenbank-Engine die Pooling-Effizienz und die Fähigkeit des Proxys, Verbindungen zu multiplexen, weiter beeinträchtigen:
-
In Amazon RDS und Aurora PostgreSQL wird Multi-Tenancy häufig implementiert, indem eine Datenbank pro Mandant verwendet wird. In PostgreSQL sind Verbindungen jedoch datenbankspezifisch: Eine Verbindung, die für eine Datenbank geöffnet wurde, kann nicht auf Daten aus anderen Datenbanken zugreifen. Daher verringert die Mehrmandantenfähigkeit auf Datenbankebene die Effizienz von Pooling und Multiplexing auf Proxyebene. Diese Überlegung gilt auch, wenn für den Workload eine Mehrmandantenfähigkeit auf Schemaebene und für Clientsitzungen eine benutzerdefinierte Methode verwendet wird.
search_pathWenn jedoch alle Sitzungen den Standardsuchpfad verwenden und auf Tabellen verweisen, die vollqualifizierte Namen (schema_name.table_name) verwenden, können diese Sitzungen gemultiplext werden. -
In Amazon RDS und Aurora MySQL sind die Begriffe „Datenbank“ und „Schema“ Synonyme. Multi-tenancy wird häufig mithilfe eines Schemas pro Mandant implementiert, was in MySQL einer Datenbank pro Mandant entspricht. Verbindungen werden für einen gesamten MySQL-Server geöffnet und sind nicht an ein Schema gebunden. Wenn die Anwendung Mehrmandantenfähigkeit auf Schemaebene verwendet, ist Verbindungsmultiplexing für Clients, die denselben Datenbankbenutzernamen verwenden, immer noch möglich, auch wenn diese Verbindungen auf Daten in unterschiedlichen Schemas zugreifen müssen. Multiplexing ist am effektivsten, wenn die Mandantentrennung auf Anwendungsebene erfolgt, anstatt für jeden Mandanten unterschiedliche Datenbankkonten zu verwenden.
In Umgebungen mit mehreren Schemas hängt die Effizienz von Multiplexing davon ab, wie Sie auf Tabellennamen verweisen:
-
Für Clients, die das aktuelle Schema mithilfe von Sitzungsvariablen (
SET search_path ...in PostgreSQL undUSE schema;in MySQL) wählen und dann unqualifizierte Tabellennamen in Abfragen verwenden (z. B.SELECT ... FROM table_name), funktioniert Verbindungsmultiplexing nur zwischen Clients, die dasselbe Schema oder denselben Suchpfad verwenden. -
Für Clients, die den Sitzungsstatus nicht ändern, um das aktuelle Schema zu definieren, sondern stattdessen vollqualifizierte Tabellennamen in den SQL-Anweisungen verwenden (z. B.
SELECT ... FROM schema_name.table_name), ist Multiplexing nicht ähnlich eingeschränkt.
Datenbanken, die mehrere Anwendungen oder Software-Stacks bedienen
Wie im vorherigen Abschnitt beschrieben, führen bestimmte Merkmale des Verbindungsstatus zwar nicht zu Pinning, beeinträchtigen aber dennoch die Fähigkeit des Proxys, Verbindungen zwischen verschiedenen Clients wiederzuverwenden. Bei Verwendung mit MySQL-Zielen verfolgt RDS Proxy eine Reihe von Anweisungen und Sitzungsvariablen, die den Sitzungsstatus konfigurieren, z. B. den Zeichensatz, die Zeitzone und die Sortierungseinstellungen. Wenn ein Client protokollierte Anweisungen oder Variablen verwendet, um Sitzungseinstellungen zu konfigurieren, kann die Proxyverbindung nur für andere Clients wiederverwendet werden, die dieselben Werte für diese Einstellungen haben.
Daher können bestimmte Anwendungs- und Treiberverhaltensweisen Ihre Fähigkeit einschränken, Verbindungen innerhalb des Proxys wiederzuverwenden. Sie könnten beispielsweise verschiedenen Anwendungen erlauben, sich mit demselben Benutzernamen mit der Datenbank zu verbinden, vorausgesetzt, dass der Proxy Verbindungen zwischen diesen Anwendungen wiederverwenden und multiplexen kann. Wenn jedoch eine Anwendung Verbindungen mit Zeitzone A (SET time_zone = ?) bootet und eine andere Anwendung Zeitzone B verwendet, sind Verbindungen innerhalb einer Anwendung wiederverwendbar, aber nicht zwischen Anwendungen. Dies führt zu einer Fragmentierung des Verbindungspools, was sich negativ auf die Effektivität von Pooling und Multiplexing auswirkt.
Weitere Informationen finden Sie unter RDS-Proxy verfolgt die folgenden Datenbanken von RDS für MariaDB und RDS für MySQL:. Die Sitzungsstatusverfolgung wird derzeit nicht für andere Datenbankziele als MySQL unterstützt.
Konfigurationsrichtlinien und bewährte Methoden Richtlinien zur Konfiguration zur Verwaltung des Sitzungsstatus zur Vermeidung von Verbindungsanhaftungen finden Sie unter.
Verwendung von Pooling auf Anwendungsebene und erweiterter Treiber mit RDS Proxy
RDS Proxy trägt zur Verbesserung der Skalierbarkeit und Verbindungseffizienz in Situationen bei, in denen die Anwendung selbst kein Verbindungspooling verwendet. Gleichzeitig enthalten viele Treiber und Frameworks Pooling-Funktionen. Möglicherweise verwenden Sie auch erweiterte Wrapper oder Treiber, die einige der Proxyfunktionen auf Treiberebene implementieren.
Die Verwendung von Pooling auf Anwendungsebene und andere Verbesserungen bei der Verbindungsverarbeitung stehen grundsätzlich nicht im Konflikt mit der Verwendung des RDS-Proxys, und seine Vorteile werden auch nicht zunichte gemacht. Möglicherweise verwenden Sie Verbindungspooling in Ihren Anwendungscontainern, aber die Anzahl der Container ist groß genug, dass Ihnen ohne die Verwendung eines Proxys immer noch die Grenzwerte für Datenbankverbindungen ausgehen würden. Wenn Sie RDS Proxy mit Pools auf Anwendungsebene und anderen verbindungsbezogenen Funktionen verwenden, sollten Sie sich mit den Gründen vertraut machen, aus denen erweiterte Funktionen zur Verbindungsverwaltung auf Anwendungsebene existieren. Entscheiden Sie, welche dieser Funktionen es wert sind, beibehalten zu werden (oder harmlos) und welche sich mit dem Proxyverhalten überschneiden oder es beeinträchtigen können. Beispiel:
-
In Treiber und Frameworks integrierte Pooling-Funktionen können auch dann nützlich sein, wenn sie sich mit der RDS-Proxy-Funktionalität zu überschneiden scheinen. Wenn ein Pool auf Anwendungsebene zusätzlich zu den Vorteilen, die der Proxy bietet, die Effizienz der lokalen Verbindungen verbessert, können Sie ihn beibehalten.
-
Funktionen im Zusammenhang mit der Failover-Behandlung können die RDS-Proxylogik beeinträchtigen oder die Gesamtkomplexität des Stacks erhöhen, ohne dass dies Vorteile bringt. Wenn Ihre Anwendung beispielsweise aktiv die Topologie Ihrer Aurora-Cluster verfolgt, um DNS-related Failover-Verzögerungen zu vermeiden, ist dies mit RDS Proxy nicht mehr erforderlich. Die Beibehaltung dieser Topologie-Tracking-Logik kann zu unerwünschtem Verhalten führen, z. B. wenn die Anwendungs-Threads den Proxy umgehen und sich direkt mit einzelnen Datenbank-Instances verbinden. In diesem Szenario können Sie die Tracking-Logik auf Anwendungsebene deaktivieren und RDS Proxy die Cluster-Topologie für Sie abstrahieren lassen.
-
Verbindungspooling-Bibliotheken verwenden möglicherweise Funktionen zur Statusverwaltung, die theoretisch nützlich erscheinen, sich jedoch negativ auf das Proxyverhalten auswirken. Ein solches Beispiel sind PostgreSQL-Bibliotheken, die die
DISCARD ALLAbfrage aufrufen, um den Verbindungsstatus zwischen Borrows zurückzusetzen. Es mag den Anschein haben, dass das Zurücksetzen von Verbindungen beim Pooling und Multiplexing helfen sollte, aber es beeinträchtigt die interne Sitzungsstatusverwaltung von Amazon RDS Proxy. Bei der Verwendung fixiert der Proxy Ihre Client-Verbindung bei der FreigabeDISCARD, wodurch die Multiplexing-Effizienz reduziert wird.
Stellen Sie bei allen Verbindungsabwicklungskomponenten auf Anwendungsebene, die Sie behalten, sicher, dass ihre Konfiguration die von Amazon RDS Proxy verwendete Verbindungsverarbeitungslogik nicht beeinträchtigt. Beispiel:
-
Passen Sie die Poolgröße auf allen Ebenen des Stacks an. Wenn die Pools auf Anwendungsebene zu groß sind (oder Ihr Proxypool zu klein ist), versucht die Anwendung möglicherweise, Verbindungen zu öffnen, für deren Verarbeitung der Proxy nicht konfiguriert ist. Bei diesen Verbindungen kann es bestenfalls zu Verzögerungen und im schlimmsten Fall zu Ablehnungsfehlern kommen.
-
Passen Sie die Timeout-Einstellungen an, um die Abwanderung zu reduzieren und Verwirrung beim Verbindungsverhalten zu vermeiden. Wenn der Anwendungspool die Verbindungen 300 Sekunden lang aufrecht hält, der Proxy jedoch so konfiguriert ist, dass Verbindungen nach 60 Sekunden geschlossen werden, wird die Verbindung in der Anwendung vorzeitig geschlossen und nicht wie erwartet.
Einige dieser architektonischen Entscheidungen und Konfigurationsentscheidungen erfordern möglicherweise Tests und Experimente. Es ist nicht immer möglich, das Anwendungsverhalten in einer Umgebung mit mehreren Ebenen von Pooling und Verbindungsmanagement exakt vorherzusagen.
Allgemeine Konfigurationsrichtlinien finden Sie unter. Richtlinien zur Konfiguration
