Ressourcen optimieren und Leseanfragen mit transparenter Abfrageweiterleitung isolieren

Vorschau – Transparente Weiterleitung von Anfragen

Diese Funktion unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Auf dieser Seite wird beschrieben, wie Sie die transparente Weiterleitung von Anfragen in Ihren AlloyDB for PostgreSQL-Instanzen aktivieren, konfigurieren und überwachen. Die transparente Weiterleitung von Anfragen ist eine intelligente Funktion zur Ressourcenoptimierung, mit der der primäre Knoten schreibgeschützte Anfragen abfangen und selektiv an unterlastete Lesepoolinstanzen weiterleiten kann, während die Read-Your-Writes-Konsistenz beibehalten wird. Abfragen, die an den Lesepool weitergeleitet werden, liefern Ergebnisse, die mit der Ausführung auf dem primären Knoten übereinstimmen.

Hinweis :Anfragen werden an Lesepoolinstanzen in der Region weitergeleitet. Abfragen werden nicht an sekundäre Cluster weitergeleitet.

Die transparente Weiterleitung von Anfragen eignet sich am besten für die folgenden Szenarien:

• Hybride Arbeitslasten (HTAP): Sie führen Berichts- oder Analyseabfragen mit Read-Your-Writes-Konsistenz in derselben Datenbank aus, in der auch Transaktionen verarbeitet werden, und möchten verhindern, dass sich teure Lesevorgänge auf die Schreiblatenz auswirken.
• Monolithische Anwendungen: Sie möchten die Lesepoolkapazität nutzen, ohne Ihre Anwendung für die Verwendung separater Lese- und Schreibendpunkte umzugestalten, und gleichzeitig eine strikte Read-Your-Writes-Konsistenz benötigen.
• Dynamisches Lastmanagement: Sie haben unvorhersehbare Spitzen beim Lesetraffic und möchten, dass die Datenbank die Arbeit automatisch auf Lesepoolknoten auslagert, wenn der primäre Knoten stark ausgelastet ist, und zwar mit Read-Your-Writes-Konsistenz.

Hinweis

• Prüfen Sie, ob Ihr AlloyDB-Cluster mit PostgreSQL 17 oder 18 kompatibel ist.

• In Ihrem AlloyDB-Cluster muss mindestens eine aktive Lesepoolinstanz konfiguriert sein. Informationen zum Erstellen oder Überprüfen von Lesepoolinstanzen finden Sie unter Lesepoolinstanz in einem Cluster erstellen und Instanzdetails ansehen.

  Hinweis :Wenn Ihr Cluster nur eine primäre oder hochverfügbare (HA) Einrichtung ohne Lesepools hat, sind für die transparente Weiterleitung von Anfragen keine Zielknoten verfügbar, an die weitergeleitete Anfragen gesendet werden können.

Erforderliche Rollen

• Achten Sie darauf, dass Sie eine Verbindung mit einem integrierten Datenbanknutzer wie postgres herstellen. Die IAM-basierte Authentifizierung wird nicht unterstützt.

Transparente Weiterleitung von Anfragen aktivieren

Die transparente Weiterleitung von Anfragen ist standardmäßig deaktiviert. Sie können die Funktion dynamisch auf Sitzungs- oder Datenbankebene aktivieren, ohne die Datenbank neu zu starten.

Auf Sitzungsebene aktivieren

Führen Sie den folgenden SQL-Befehl aus, um die transparente Abfrageweiterleitung für Ihre aktuelle Sitzung zu aktivieren:

SET alloydb.enable_query_forwarding = TRUE;

Auf Datenbankebene aktivieren

Führen Sie den folgenden SQL-Befehl aus, um die transparente Weiterleitung von Anfragen für eine bestimmte Datenbank zu aktivieren:

ALTER DATABASE DATABASE_NAME SET alloydb.enable_query_forwarding = ON;

Ersetzen Sie DATABASE_NAME durch den Namen Ihrer Datenbank.

Hinweis :Nachdem Sie den Befehl ALTER DATABASE ausgeführt haben, wird die transparente Abfrageweiterleitung für neue Verbindungen zur Datenbank aktiviert.

Bedingungen für die Abfrageberechtigung

• Die transparente Weiterleitung von Abfragen gilt nur für schreibgeschützte SELECT-Anweisungen.
• Für die Abfrage dürfen keine Sperren auf Zeilenebene verwendet werden, z. B. solche, die in SELECT ... FOR UPDATE verwendet werden.
• Die transparente Weiterleitung von Abfragen bietet nur eingeschränkte Unterstützung für SELECT-Anweisungen in Transaktionen mit mehreren Anweisungen.
• Abfragen können nicht auf temporäre, nicht protokollierte oder Katalogtabellen verweisen.
• Die Abfrage muss die folgenden Funktionseinschränkungen erfüllen:
  • Die Abfrage darf keine flüchtigen Funktionen oder benutzerdefinierten Funktionen (UDFs) enthalten.
  • Die Abfrage darf keine SQL-Wertfunktionen wie CURRENT_DATE, LOCALTIME, USER oder CURRENT_SCHEMA enthalten.
  • Die Abfrage darf keine NEXTVAL()-Ausdrücke enthalten.
  • Die Abfrage darf keine SQL-Prozeduren oder SQL-Funktionen enthalten.
• Für alle Ergebnisspalten müssen Datentypen verwendet werden, die binäre Sende- und Empfangsfunktionen implementieren.
• Eine Anfrage kommt nur für die Weiterleitung infrage, wenn die Gemeinkosten im Vergleich zu den Gesamtkosten der Anfrage minimal sind. Das bedeutet, dass Abfragen mit Indexscans in der Regel ausgeschlossen werden, da ihr Overhead in der Regel die Kosten der Abfrage selbst übersteigt.
• Die Weiterleitung an einen AlloyDB-Hot-Standby-Knoten wird nicht unterstützt. Ein AlloyDB-Hot-Standby-Knoten ist ein dedizierter sekundärer Knoten für primäre Hochverfügbarkeitsinstanzen (HA).
• Die Abfrage muss das Simple Query Protocol verwenden. Das erweiterte Abfrageprotokoll wird nicht unterstützt.

Mit EXPLAIN prüfen, ob eine Abfrage ausgeführt werden kann

Im folgenden Beispiel ist large_table eine Tabelle in einer Datenbank mit vielen Zeilen. Führen Sie den Befehl EXPLAIN aus, um zu prüfen, ob eine bestimmte Anfrage gemäß Ihrer aktuellen Konfiguration weitergeleitet werden kann:

EXPLAIN SELECT count(*) FROM large_table t1, large_table t2;

Wenn die Abfrage infrage kommt, enthält die Ausgabe nach dem Standard-Postgres-Ausführungsplan eine Statusanweisung zur Abfrageweiterleitung. Wenn diese Anweisung fehlt, kommt die Abfrage nicht für die Weiterleitung infrage und wird lokal auf dem primären Knoten ausgeführt.

Aggregate  (cost=25000.00..25000.01 rows=1 width=8)
  ->  Nested Loop  (cost=0.00..20000.00 rows=1000000 width=0)
        ... [Standard Postgres Plan Steps] ...
Query Forwarding: Eligible. (overhead=1250.02)

In der Ausgabereaktion gibt Eligible an, dass die Abfrage den Standardkriterien für schreibgeschütztes SQL entspricht und die Kosten-Nutzen-Analyse die Weiterleitung an eine Instanz des Lesepools empfiehlt. Der Parameter overhead gibt die berechneten Planner-Kosten für das Weiterleiten der Anfrage an eine Lesepoolinstanz an, einschließlich des Overheads für das Herstellen der Verbindung und das Wiederherstellen von Snapshots auf dem Replikat.

Messwerte für die Weiterleitung von Anfragen überwachen

Um zu prüfen, ob die transparente Weiterleitung von Anfragen für Ihre Arbeitslast funktioniert, können Sie den folgenden Messwert in Cloud Monitoring im Blick behalten:

Messwert	Beschreibung	Details
alloydb.googleapis.com/internal/database/postgresql/workload/distributed/tqf_query_count	Die kumulative Anzahl der Anfragen, die durch die transparente Weiterleitung von Anfragen verarbeitet wurden.	Anzeigename:Anzahl der TQF-Anfragen Messwertart:CUMULATIVE Werttyp:INT64 Labels: status: Verarbeitung von Anfragen, wenn die transparente Weiterleitung von Anfragen aktiviert ist. Für dieses Label wird einer der folgenden Werte erfasst: completed: wird auf einer Lesepoolinstanz ausgeführt. fallback: auf dem primären Gerät ausgeführt. disqualified: konnte nicht weitergeleitet werden.

Nächste Schritte

• Lesepoolinstanz in einem Cluster erstellen
• Instanzen überwachen