Vermeiden von Pinning beim RDS-Proxy - Amazon Aurora
Welche Daten RDS-Proxy für Aurora-MySQL-Datenbanken verfolgtMinimieren des FixierensBedingungen, die für alle Engine-Familien zum Pinning führenBedingungen, die das Fixieren für Aurora MySQL verursachenBedingungen, die das Fixieren für Aurora PostgreSQL verursachen

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.

Vermeiden von Pinning beim RDS-Proxy

Multiplexing ist effizienter, wenn Datenbankanforderungen nicht auf Statusinformationen aus früheren Anforderungen angewiesen sind. In diesem Fall kann RDS-Proxy eine Verbindung zum Abschluss jeder Transaktion wiederverwenden. Beispiele für solche Zustandsinformationen sind die meisten Variablen und Konfigurationsparameter, die Sie durch SET-oder SELECT-Anweisungen ändern können. SQL-Transaktionen auf einer Clientverbindung können standardmäßig zwischen zugrunde liegenden Datenbankverbindungen Multiplexing durchführen.

Ihre Verbindungen zum Proxy können einen Status eingeben, der als Pinning (Fixieren) bezeichnet wird. Wenn eine Verbindung angeheftet wird, verwendet jede spätere Transaktion dieselbe zugrunde liegende Datenbankverbindung, bis die Sitzung beendet ist. Andere Clientverbindungen können diese Datenbankverbindung auch erst dann wieder verwenden, wenn die Sitzung beendet ist. Die Sitzung wird beendet, wenn die Clientverbindung unterbrochen wird.

RDS-Proxy heftet automatisch eine Clientverbindung an eine bestimmte DB-Verbindung an, wenn eine Sitzungsstatusänderung erkannt wird, die für andere Sitzungen nicht geeignet ist. Das Fixieren verringert die Effektivität der Wiederverwendung der Verbindung. Wenn alle oder fast alle Verbindungen fixiert sind, können Sie Ihren Anwendungscode oder Ihre Workload ändern, um dafür zu sorgen, dass Fixierungen weniger erforderlich sind.

Ihre Anwendung ändert beispielsweise eine Sitzungsvariable oder einen Konfigurationsparameter. In diesem Fall können sich spätere Anweisungen darauf verlassen, dass die neue Variable oder der neue Parameter wirksam ist. Wenn also RDS-Proxy Anforderungen verarbeitet, um Sitzungsvariablen oder Konfigurationseinstellungen zu ändern, wird diese Sitzung an die DB-Verbindung fixiert. Auf diese Weise bleibt der Sitzungsstatus für alle späteren Transaktionen in derselben Sitzung gültig.

Bei Datenbank-Engines gilt diese Regel nicht für alle Parameter, die Sie festlegen können. RDS-Proxy verfolgt bestimmte Anweisungen und Variablen. RDS-Proxy nimmt somit kein Pinning einer Sitzung vor, wenn Sie diese ändern. In diesem Fall verwendet RDS-Proxy nur die Verbindung für andere Sitzungen erneut, die dieselben Werte für diese Einstellungen haben. Die Listen der verfolgten Anweisungen und Variablen für Aurora MySQL finden Sie unter Welche Daten RDS-Proxy für Aurora-MySQL-Datenbanken verfolgt.

Welche Daten RDS-Proxy für Aurora-MySQL-Datenbanken verfolgt

RDS-Proxy verfolgt die folgenden MySQL-Anweisungen:

  • DROP DATABASE

  • DROP SCHEMA

  • USE

RDS-Proxy verfolgt die folgenden MySQL-Variablen:

  • AUTOCOMMIT

  • AUTO_INCREMENT_INCREMENT

  • CHARACTER SET (or CHAR SET)

  • CHARACTER_SET_CLIENT

  • CHARACTER_SET_DATABASE

  • CHARACTER_SET_FILESYSTEM

  • CHARACTER_SET_CONNECTION

  • CHARACTER_SET_RESULTS

  • CHARACTER_SET_SERVER

  • COLLATION_CONNECTION

  • COLLATION_DATABASE

  • COLLATION_SERVER

  • INTERACTIVE_TIMEOUT

  • NAMES

  • NET_WRITE_TIMEOUT

  • QUERY_CACHE_TYPE

  • SESSION_TRACK_SCHEMA

  • SQL_MODE

  • TIME_ZONE

  • TRANSACTION_ISOLATION (or TX_ISOLATION)

  • TRANSACTION_READ_ONLY (or TX_READ_ONLY)

  • WAIT_TIMEOUT

Anmerkung

RDS-Proxy verfolgt Änderungen an den Variablen TRANSACTION_ISOLATION und TRANSACTION_READ_ONLY, wenn Sie sie im Sitzungsbereich festlegen. Wenn Sie sie jedoch für den nächsten Transaktionsbereich festlegen, heftet der RDS-Proxy Verbindungen an. Dieses Verhalten gilt unabhängig davon, ob Sie eine SET- oder eine SET TRANSACTION-Anweisung verwenden, um diese Werte zu konfigurieren.

Minimieren des Fixierens

Die Leistungsoptimierung für RDS-Proxy beinhaltet den Versuch, die Wiederverwendung von Verbindungen auf Transaktionsebene (Multiplexing) zu maximieren, indem das Fixieren minimiert wird.

Sie können das Fixieren wie folgt minimieren:

  • Vermeiden Sie unnötige Datenbankanforderungen, die Anheften (Pinning) verursachen könnten.

  • Legen Sie Variablen und Konfigurationseinstellungen konsistent über alle Verbindungen hinweg fest. Auf diese Weise verwenden spätere Sitzungen häufiger Verbindungen, die über diese speziellen Einstellungen verfügen.

    Wenn für PostgreSQL jedoch eine Variable festgelegt wird, wird die Sitzung durch Pinning fixiert.

  • Wenden Sie bei einer MySQL-Engine-Familiendatenbank einen Sitzungs-Pinning-Filter auf den Proxy an. Sie können bestimmte Arten von Operationen vom Fixieren der Sitzung ausnehmen, wenn Sie wissen, dass dies den korrekten Betrieb Ihrer Anwendung nicht beeinträchtigt.

  • Stellen Sie fest, wie häufig das Fixieren auftritt, indem Sie die Amazon-CloudWatch-Metrik DatabaseConnectionsCurrentlySessionPinned überwachen. Hinweise zu diesen und anderen CloudWatch-Metriken finden Sie unter Überwachen von RDS-Proxy-Metriken mit Amazon CloudWatch.

  • Wenn Sie SET-Anweisungen verwenden, um eine identische Initialisierung für jede Clientverbindung durchzuführen, können Sie dies tun, während Sie das Multiplexing auf Transaktionsebene beibehalten. In diesem Fall verschieben Sie die Anweisungen, die den ursprünglichen Sitzungsstatus einrichten, in die Initialisierungsabfrage, die von einem Proxy verwendet wird. Diese Eigenschaft ist eine Zeichenfolge, die eine oder mehrere SQL-Anweisungen enthält, die durch Semikola getrennt sind.

    Beispielsweise können Sie eine Initialisierungsabfrage für einen Proxy definieren, der bestimmte Konfigurationsparameter festlegt. RDS-Proxy wendet dann diese Einstellungen an, wenn eine neue Verbindung für diesen Proxy eingerichtet wird. Sie können die entsprechenden SET-Anweisungen aus Ihrem Anwendungscode entfernen, damit sie das Multiplexing auf Transaktionsebene nicht beeinträchtigen.

    Metriken zur Häufigkeit des Pinnings für einen Proxy finden Sie unter Überwachen von RDS-Proxy-Metriken mit Amazon CloudWatch.

Bedingungen, die für alle Engine-Familien zum Pinning führen

Der Proxy fixiert die Sitzung an der aktuellen Verbindung in den folgenden Situationen an, in denen Multiplexing unerwartetes Verhalten verursachen kann:

  • Jede Anweisung mit einer Textgröße über 16 KB bewirkt, dass der Proxy die Sitzung fixiert.

Bedingungen, die das Fixieren für Aurora MySQL verursachen

Bei MySQL verursachen die folgenden Interaktionen ein Pinning:

  • Die expliziten MySQL-Anweisungen LOCK TABLE, LOCK TABLES oder FLUSH TABLES WITH READ LOCK bewirken, dass der Proxy ein Pinning der Sitzung vornimmt.

  • Durch Erstellen benannter Sperren mit GET_LOCK wird bewirkt, dass der Proxy ein Pinning der Sitzung vornimmt.

  • Wenn Sie eine Benutzervariable oder eine Systemvariable festlegen (mit einigen Ausnahmen), wird die Sitzung an den Proxy angeheftet. Wenn dadurch die Wiederverwendung von Verbindungen erheblich eingeschränkt wird, können Sie SET-Vorgänge so konfigurieren, dass das Pinning vermieden wird. Passen Sie dazu die Eigenschaft für Sitzungs-Pinning-Filter an. Weitere Informationen erhalten Sie unter Erstellen eines Proxys für Amazon Aurora und Ändern eines RDS-Proxy.

  • Beim Erstellen einer temporären Tabelle fixiert der Proxy die Sitzung. Auf diese Weise wird der Inhalt der temporären Tabelle während der gesamten Sitzung beibehalten, unabhängig von den Transaktionsgrenzen.

  • Der Aufruf der Funktionen ROW_COUNT und FOUND_ROWS verursacht manchmal Pinning.

    Die genauen Umstände, unter denen diese Funktionen Pinning verursachen, können sich zwischen Aurora-MySQL-Versionen unterscheiden, die mit MySQL 5.7 kompatibel sind.

  • Vorbereitete Anweisungen bewirken, dass der Proxy die Sitzung fixiert. Diese Regel bestimmt, ob die vorbereitete Anweisung SQL-Text oder das Binärprotokoll verwendet.

  • RDS-Proxy pingt keine Verbindungen an, wenn Sie SET LOCAL verwenden.

  • Das Aufrufen von gespeicherten Prozeduren und gespeicherten Funktionen verursacht kein Pinning. RDS-Proxy erkennt keine Änderungen des Sitzungsstatus, die aus solchen Aufrufen resultieren. Stellen Sie sicher, dass Ihre Anwendung den Sitzungsstatus in gespeicherten Routinen nicht ändert, wenn Sie darauf angewiesen sind, dass dieser Sitzungsstatus transaktionsübergreifend beibehalten wird. Beispielsweise ist RDS-Proxy derzeit nicht mit einer gespeicherten Prozedur kompatibel, die eine temporäre Tabelle erstellt, die transaktionsübergreifend bestehen bleiben soll.

Wenn Sie über eingehende Kenntnisse über das Verhalten Ihrer Anwendung verfügen, können Sie das Pinning-Verhalten für bestimmte Anwendungsanweisungen überspringen. Dazu wählen Sie beim Erstellen des Proxys die Option Sitzungs-Pinning-Filter. Derzeit können Sie das Sitzungs-Pinning für das Festlegen von Sitzungsvariablen und Konfigurationseinstellungen deaktivieren.

Bedingungen, die das Fixieren für Aurora PostgreSQL verursachen

Für PostgreSQL verursachen die folgenden Interaktionen eine Fixierung:

  • Verwenden von SET-Befehlen

  • Verwenden der Befehle PREPARE, DISCARD, DEALLOCATE oder EXECUTE zur Verwaltung von vorbereiteten Anweisungen

  • Erstellen von temporären Sequenzen, Tabellen oder Ansichten

  • Deklarieren von Cursors

  • Verwerfen des Sitzungsstatus

  • Listening für einen Benachrichtigungskanal

  • Laden eines Bibliotheksmoduls wie auto_explain

  • Manipulieren von Sequenzen mit Funktionen wie nextval und setval

  • Interagieren mit Sperren mit Funktionen wie pg_advisory_lock und pg_try_advisory_lock

    Anmerkung

    RDS-Proxy führt kein Pinning für Advisor-Sperren auf Transaktionsebene durch. Dies gilt insbesondere für pg_advisory_xact_lock, pg_advisory_xact_lock_shared, pg_try_advisory_xact_lock und pg_try_advisory_xact_lock_shared.

  • Festlegen eines Parameters oder Zurücksetzen eines Parameters auf den Standardwert Insbesondere die Verwendung der Befehle SET und set_config zum Zuweisen von Standardwerten zu Sitzungsvariablen.

  • Das Aufrufen von gespeicherten Prozeduren und gespeicherten Funktionen verursacht kein Pinning. RDS-Proxy erkennt keine Änderungen des Sitzungsstatus, die aus solchen Aufrufen resultieren. Stellen Sie sicher, dass Ihre Anwendung den Sitzungsstatus in gespeicherten Routinen nicht ändert, wenn Sie darauf angewiesen sind, dass dieser Sitzungsstatus transaktionsübergreifend beibehalten wird. Beispielsweise ist RDS-Proxy derzeit nicht mit einer gespeicherten Prozedur kompatibel, die eine temporäre Tabelle erstellt, die transaktionsübergreifend bestehen bleiben soll.

  • Verwerfen des Sitzungsstatus Wenn Sie Verbindungspooling-Bibliotheken verwenden, deren DISCARD ALL-Abfrage als Reset-Abfrage konfiguriert ist, fixiert RDS-Proxy Ihre Client-Verbindung bei der Freigabe. Dies verringert die Effizienz des Multiplexings des Proxys und kann zu unerwarteten Ergebnissen führen, da der Befehl DISCARD ALL die Sitzungsstatusverwaltung beeinträchtigen kann.