Vermeiden Sie das Anheften eines Proxys RDS - Amazon Aurora
Was RDS Proxy für Aurora My SQL Datenbanken verfolgtMinimieren des FixierensBedingungen, die für alle Engine-Familien zum Pinning führenBedingungen, die dazu führen, dass Aurora My angeheftet wird SQLBedingungen, die dazu führen, dass Aurora Postgre angeheftet wird SQL

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 Sie das Anheften eines Proxys RDS

Multiplexing ist effizienter, wenn Datenbankanforderungen nicht auf Statusinformationen aus früheren Anforderungen angewiesen sind. In diesem Fall kann der RDS Proxy eine Verbindung nach 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. SQLTransaktionen auf einer Clientverbindung können standardmäßig zwischen den zugrunde liegenden Datenbankverbindungen multiplexen.

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.

RDSEin Proxy verbindet eine Client-Verbindung automatisch mit einer bestimmten DB-Verbindung, wenn er eine Änderung des Sitzungsstatus erkennt, 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 der RDS Proxy also Anfragen zur Änderung von Sitzungsvariablen oder Konfigurationseinstellungen verarbeitet, bindet er diese Sitzung an die DB-Verbindung. 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. RDSDer Proxy verfolgt bestimmte Anweisungen und Variablen. Daher fixiert RDS Proxy die Sitzung nicht, wenn Sie sie ändern. In diesem Fall verwendet RDS Proxy die Verbindung nur für andere Sitzungen, die dieselben Werte für diese Einstellungen haben. Eine Liste der verfolgten Anweisungen und Variablen für Aurora My SQL finden Sie unterWas RDS Proxy für Aurora My SQL Datenbanken verfolgt.

Was RDS Proxy für Aurora My SQL Datenbanken verfolgt

Im Folgenden sind meine SQL Aussagen aufgeführt, die RDS Proxy verfolgt:

  • DROP DATABASE

  • DROP SCHEMA

  • USE

Im Folgenden sind die SQL Variablen „Meine“ aufgeführt, die der RDS Proxy verfolgt:

  • 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

Minimieren des Fixierens

Bei der Leistungsoptimierung für RDS Proxy wird versucht, die Wiederverwendung von Verbindungen auf Transaktionsebene (Multiplexing) zu maximieren, indem das Pinning 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.

    Bei Postgre führt das Setzen einer Variablen jedoch zu SQL Session-Pinning.

  • Wenden Sie für eine Datenbank der My SQL Engine-Familie 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.

  • Sehen Sie sich anhand der CloudWatch Amazon-Metrik DatabaseConnectionsCurrentlySessionPinned an, wie häufig das Anheften erfolgt. Informationen zu dieser und anderen CloudWatch Kennzahlen 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 durch Semikolons getrennte SQL Anweisungen enthält.

    Beispielsweise können Sie eine Initialisierungsabfrage für einen Proxy definieren, der bestimmte Konfigurationsparameter festlegt. Dann wendet RDS Proxy diese Einstellungen an, wenn es eine neue Verbindung für diesen Proxy einrichtet. 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 dazu führen, dass Aurora My angeheftet wird SQL

Bei My führen SQL die folgenden Interaktionen ebenfalls zu 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 der Proxy die Sitzung fixieren. Wenn durch diese Situation die Wiederverwendung von Verbindungen zu stark eingeschränkt wird, wählen Sie die SET Vorgänge aus, bei denen das Anheften nicht verursacht wird. Weitere Informationen dazu, wie Sie dies tun, indem Sie die Eigenschaft „Session pinning filters“ festlegen, finden Sie unter Einen RDS Proxy erstellen und RDSProxy ändern.

  • 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, FOUND_ROWS und LAST_INSERT_ID verursacht manchmal Pinning.

    Die genauen Umstände, unter denen diese Funktionen zum Fixieren führen, können je nach SQL Version von Aurora My, die mit My SQL 5.7 kompatibel sind, unterschiedlich sein.

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

  • RDSDer Proxy verbindet keine Verbindungen, wenn Sie ihn verwenden SETLOCAL.

  • Das Aufrufen von gespeicherten Prozeduren und gespeicherten Funktionen verursacht kein Pinning. RDSDer Proxy erkennt keine Änderungen des Sitzungsstatus, die sich aus solchen Aufrufen ergeben. 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 für alle Transaktionen beibehalten wird.

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 dazu führen, dass Aurora Postgre angeheftet wird SQL

Bei Postgre führen SQL die folgenden Interaktionen ebenfalls zum Fixieren:

  • Befehle verwendenSET.

  • Verwendung von EXECUTE Befehlen PREPARE DISCARDDEALLOCATE,, oder zur Verwaltung vorbereiteter Anweisungen.

  • Erstellen temporärer Sequenzen, Tabellen oder Ansichten.

  • Cursor deklarieren.

  • Der Sitzungsstatus wird verworfen.

  • Abhören auf einem Benachrichtigungskanal.

  • Laden eines Bibliotheksmoduls wieauto_explain.

  • Manipulieren von Sequenzen mit Funktionen wie nextval undsetval.

  • Interaktion mit Sperren mithilfe von Funktionen wie pg_advisory_lock undpg_try_advisory_lock.

    Anmerkung

    RDSDer Proxy bindet keine Hinweissperren auf Transaktionsebenepg_advisory_xact_lock, insbesondere nicht an pg_advisory_xact_lock_sharedpg_try_advisory_xact_lock, undpg_try_advisory_xact_lock_shared.

  • Einstellung eines Parameters oder Zurücksetzen eines Parameters auf seine Standardwerte. Insbesondere die Verwendung von set_config Befehlen SET und zum Zuweisen von Standardwerten zu Sitzungsvariablen.

  • Das Aufrufen von gespeicherten Prozeduren und gespeicherten Funktionen verursacht kein Pinning. RDSDer Proxy erkennt keine Änderungen des Sitzungsstatus, die sich aus solchen Aufrufen ergeben. 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 für alle Transaktionen beibehalten wird.