Fremdtabellen mit Aurora Global Database verwenden

Aurora Global Database unterstützt die Ausführung analytischer Abfragen mit regionsspezifischer Einrichtung. In diesem Abschnitt wird beschrieben, wie analytische Abfragen regionsübergreifend konfiguriert werden, welche Ressourcen automatisch repliziert werden und wie Notfallwiederherstellungsszenarien geplant werden.

Verwenden von aurora_analytics mit einer globalen Datenbank

Eine Fremdtabelle ist eine PostgreSQL-Tabellendefinition, die auf Ihre Apache Iceberg- oder Parquet-Daten in Amazon S3, Amazon S3 S3-Tabellen oder dem verweist. AWS Glue Data Catalog Es werden keine Daten nach Aurora kopiert. Nur die folgenden Daten replizieren vom primären DB-Cluster auf jeden sekundären DB-Cluster:

• Die Installation der aurora_analytics Erweiterung

• Definitionen ausländischer Tabellen (DDL)

Die folgenden Daten werden nicht repliziert und müssen unabhängig voneinander in jeder Region bereitgestellt werden, die einen sekundären DB-Cluster enthält:

• Die IAM-Rollenzuweisung zum DB-Cluster

• Die IAM-Richtlinie, die Zugriff auf Amazon S3- oder Amazon S3 S3-Tabellen gewährt AWS Glue

• VPC-Netzwerke (Endpunkte oder NAT), die verwendet werden, um diese Dienste zu erreichen

Einrichtung in einer globalen Datenbank

Schritt 1: Erstellen Sie die IAM-Richtlinie und die IAM-Rolle in jeder Region

Die IAM-Rollenzuordnung wird nicht zwischen dem primären und dem sekundären DB-Cluster repliziert. Sie müssen in jeder Region, die einen primären oder sekundären DB-Cluster enthält, eine IAM-Rolle mit dem AuroraAnalytics Feature-Namen erstellen und ihnen zuordnen.

1. Erstellen Sie eine IAM-Richtlinie, die Lesezugriff auf Ihre Daten gewährt. Die erforderlichen Berechtigungen hängen von Ihrem Datenformat ab. Weitere Informationen finden Sie unter Referenz zu IAM-Richtlinien.

2. Erstellen Sie eine IAM-Rolle, der Sie vertrauen, rds.amazonaws.com und fügen Sie die Richtlinie hinzu.

3. Ordnen Sie die Rolle dem DB-Cluster dieser Region zu:

   aws rds add-role-to-db-cluster \
     --db-cluster-identifier <cluster-in-this-region> \
     --role-arn arn:aws:iam::<account-id>:role/AuroraAnalyticsRole \
     --feature-name AuroraAnalytics

4. Warten Sie, bis der Rollenstatus als Aktiv angezeigt wird.

Anmerkung

Unmittelbar nach dem Anhängen einer Rolle (oder nachdem eine Instanz gestartet oder heraufgestuft wurde), können Abfragen für fremde Tabellen kurzzeitig den folgenden Fehler zurückgeben:credential to access AWS service is unavailable. Warten Sie, bis der Rollenstatus Aktiv lautet, bevor Sie Abfragen für fremde Tabellen ausführen.

Schritt 2: Richten Sie das Netzwerk in jeder Region ein

Die VPC-Konfiguration wird auch nicht repliziert. Geben Sie in der VPC für jeden DB-Cluster (primär und jeden sekundären) einen Netzwerkpfad zu den erforderlichen Diensten an, sodass der DB-Cluster die Fremdtabellendaten erreichen kann, um Abfragen zu lösen. Stellen Sie sicher, dass die Cluster-Netzwerkkonfiguration jedes sekundären Netzwerks den Zugriff auf die Region der ausländischen Tabelle ermöglicht.

Erforderliche VPC-Endpunkte für jede Region

Service	Endpunkttyp	Erforderlich für
Amazon S3 (com.amazonaws.<region>.s3)	Gateway	Zugriff auf alle Daten von Amazon S3 und Amazon S3 Tables
AWS Glue (com.amazonaws.<region>.glue)	Schnittstelle	AWS Glue Data Catalog Zugriff (Iceberg-Tabellen)
AWS STS (com.amazonaws.<region>.sts)	Schnittstelle	Abrufen von Anmeldeinformationen für die IAM-Rolle

Aktivieren Sie für die Endpunkte AWS Glue und die AWS STS Schnittstelle Private DNS und lassen Sie eingehendes TCP 443 von Ihrer VPC CIDR zu.

Schritt 3: Installieren Sie die Erweiterung auf der Primärseite

Connect zur Writer-DB-Instance im primären DB-Cluster her und installieren Sie die Erweiterung in jeder Datenbank, in der Sie Fremdtabellen erstellen möchten:

CREATE EXTENSION aurora_analytics;

Die Erweiterung repliziert automatisch auf jeden sekundären DB-Cluster.

Schritt 4: Erstellen Sie Fremdtabellen auf der Primärtabelle

Erstellen Sie auf der Writer-DB-Instance im primären DB-Cluster Fremdtabellen, die auf Ihre Daten verweisen:

-- Parquet via S3 URI
CREATE FOREIGN TABLE ft_orders ()
SERVER aurora_analytics_server
OPTIONS (location 's3://my-bucket/orders/',
         format 'parquet', region 'us-east-1');

-- Iceberg via Glue ARN
CREATE FOREIGN TABLE ft_transactions ()
SERVER aurora_analytics_server
OPTIONS (location 'arn:aws:glue:us-east-1:123456789012:table/mydb/transactions',
         format 'iceberg');

Aurora repliziert die DDL in jeden sekundären DB-Cluster, in dem die Fremdtabellen für Abfragen verfügbar sind.

Schritt 5: Überprüfen Sie auf der Sekundärseite

Stellen Sie eine Connect zu einem sekundären DB-Cluster her und bestätigen Sie die Replikation und den Lesezugriff:

SELECT extname, extversion FROM pg_extension WHERE extname = 'aurora_analytics';
SELECT count(*) FROM ft_orders;

Fixierung von Fremdtabellen nach Regionen

Wenn Sie eine Fremdtabelle erstellen, Region werden deren Daten location und Daten in der Tabellendefinition gespeichert und in jeden DB-Cluster in der globalen Datenbank repliziert. Jeder DB-Cluster liest vom gleichen Standort aus.

Das bedeutet:

• Jeder sekundäre DB-Cluster liest Fremdtabellendaten aus der in der Tabellendefinition angegebenen Region.

• Wenn sich diese Region von der Region der sekundären Region unterscheidet, sind die Lesevorgänge regionsübergreifend, was die Datenübertragungskosten und die Latenz erhöht.

• Die IAM-Rolle und das Netzwerk jeder sekundären Tabelle ermöglichen es, die Region der ausländischen Tabelle zu erreichen.

Anmerkung

Amazon S3 Multi-Region Access Points (MRAPs) werden nicht als Speicherort für ausländische Tabellen unterstützt. Aurora PostgreSQL akzeptiert in der Option nur s3:// URIs, AWS Glue Tabellen-ARNs und Amazon S3 S3-Tabellen-ARNs. location MRAP-ARNs und MRAP-Hostnamen sind für diese Option nicht gültig. location

Allgemeine Hinweise zur DR-Bereitschaft

Schließen Sie die Einrichtung pro Region in den Schritten 1—2 für den sekundären DB-Cluster ab und entscheiden Sie dann, wie der DB-Cluster auf fremde Tabellendaten zugreift:

• Regionsübergreifende Lesevorgänge akzeptieren: Dieser Ansatz eignet sich nur für geplante Switchover-Szenarien, bei denen die ursprüngliche Region intakt ist.

• Pre-stage eine Region-local Kopie: Verwenden Sie Amazon S3 Cross-Region Replication, damit analytische Abfragen lokal gelesen werden können, auch wenn die ursprüngliche Region nicht verfügbar ist. Bereiten Sie ALTER FOREIGN TABLE ... OPTIONS (SET ...) Anweisungen vor, um die Speicherorte der ausländischen Tabellen so zu aktualisieren, dass sie auf die Region-local Kopie verweisen.

Anmerkung

Der Lesecache auf der Festplatte wird nicht dauerhaft gespeichert oder übertragen, wenn ein Switchover oder Failover stattfindet. Die ersten Abfragen nach dem Ereignis lesen Daten aus Amazon S3 und werden mit höherer Latenz ausgeführt, bis sich der Cache erwärmt.

Handhabung von Switchover und Failover

Während eines Aurora Global Database-Switchovers oder -Failovers haben Fremdtabellenabfragen eine zusätzliche Abhängigkeit, die über die standardmäßigen Datenbank-Client-Verbindungen hinausgeht: Sie müssen Amazon S3 und AWS STS in der Region erreichen AWS Glue, die von jeder Fremdtabelle benannt wird.

Globaler Datenbank-Switchover

Sowohl der primäre als auch der sekundäre DB-Cluster sind zum Zeitpunkt des Switchovers fehlerfrei. Sobald der neue primäre DB-Cluster verfügbar ist, lesen Abfragen weiterhin aus der Region, die in jeder Fremdtabelle angegeben ist. Wenn sich diese Region von der Region des neuen Autors unterscheidet, sind Lesevorgänge regionsübergreifend und verursachen Datenübertragungskosten und Latenz. Um eine regionsübergreifende Leselatenz zu vermeiden, führen Sie die vorbereiteten ALTER FOREIGN TABLE ... OPTIONS (SET ...) Anweisungen aus, um fremde Tabellen auf eine Kopie umzuverweisen. Region-local

Wiederaufnahme des Betriebs nach einem Switchover

1. Ermöglicht es den Clients, sich wieder mit dem Writer-Endpunkt des neuen primären DB-Clusters zu verbinden.

2. Warten Sie, bis der IAM-Rollenstatus Aktiv lautet. Führen Sie eine Testabfrage für eine Fremdtabelle (z. B.SELECT count(*) FROM ft_orders) mit Wiederholungslogik aus, um zu überprüfen, ob Analyseabfragen betriebsbereit sind.

3. Wenn Region-local Sie eine Kopie verwenden, führen Sie die vorbereiteten ALTER Anweisungen auf dem neuen primären DB-Cluster aus, um die Speicherorte der Fremdtabellen zu aktualisieren:

   ALTER FOREIGN TABLE ft_orders OPTIONS (SET location 's3://dr-region-bucket/orders/', SET region 'us-west-2');
   ALTER FOREIGN TABLE ft_transactions OPTIONS (SET location 'arn:aws:glue:us-west-2:123456789012:table/mydb/transactions');

Anmerkung

ALTER FOREIGN TABLE ... OPTIONS (SET ...)ist eine Änderung, die nur für Katalogmetadaten bestimmt ist. Sie wird sofort abgeschlossen, ohne dass Daten verschoben werden. Es erfordert eine kurze ACCESS EXCLUSIVE Sperre für diese einzelne Fremdtabelle. Daher wird sie durch jede laufende Abfrage in derselben Tabelle blockiert.

Globales Datenbank-Failover

Die ursprüngliche Region ist möglicherweise beeinträchtigt oder nicht erreichbar. Wenn eine Fremdtabelle die beeinträchtigte Region benennt, kommt es bei Abfragen zu dieser Region zu einer hohen Latenz oder sie schlagen mit Timeoutfehlern fehl, bis diese Region wiederhergestellt ist oder Sie die Fremdtabelle erneut auf Daten in einer fehlerfreien Region verweisen. Wenn Sie eine Region-local Kopie vorab bereitgestellt haben, führen Sie die vorbereiteten ALTER FOREIGN TABLE ... OPTIONS (SET region ...) Anweisungen aus, um fremde Tabellen auf die Kopie zu verweisen. Region-local

Zurück zur ursprünglichen Hauptregion

Wenn die ursprüngliche primäre Region verfügbar ist, fügt Aurora sie automatisch als sekundäres DB-Cluster wieder zur globalen Datenbank hinzu. Alle während des Switchovers oder Failovers ALTER FOREIGN TABLE vorgenommenen Änderungen werden durch globale Replikation darauf repliziert. Um die ursprüngliche primäre Region wiederherzustellen, führen Sie einen Switchover durch. Stellen Sie nach Abschluss des Switchovers fest, ob die Speicherorte der fremden Tabellen so wiederhergestellt werden sollen, dass sie auf Daten in der wiederhergestellten primären Region verweisen.

Fehlermeldungen in einer globalen Datenbank

Nach einem Switchover oder Failover können Abfragen in der neuen primären Region mit derselben IAM-Rollenzuweisung, denselben IAM-Berechtigungen und Netzwerkfehlern fehlschlagen, die sich auf alle Regionen auswirken, in denen ein sekundärer DB-Cluster ausgeführt wird. Diese Fehler und ihre Lösungen werden im Abschnitt Globaler Datenbank-Switchover und Failover unter behandelt. Überwachung und Problembehebung Die Voraussetzungen müssen in jeder sekundären Region erfüllt sein, da die IAM-Rollenzuordnung, die IAM-Richtlinie und das VPC-Netzwerk nicht repliziert werden.

• Fremdtabelle location und region sind eine einzelne replizierte Definition ohne Überschreibung pro Region. Beide Cluster können nicht unterschiedliche Regionen für dieselbe Tabelle enthalten.

• Amazon S3 Multi-Region Access Points und Amazon S3 Access-Point-ARNs werden nicht als ausländische Tabellenstandorte unterstützt.

• VPC-Gateway-Endpunkte sind regional und können den Amazon S3 einer anderen Region nicht erreichen. Ein regionsübergreifender Netzwerkpfad erfordert NAT/internet Egress oder Transit Gateway.

• Nach einem Switchover führt die Aktualisierung eines fremden Tabellenstandorts auf die Region des neuen primären DB-Clusters dazu, dass der frühere primäre DB-Cluster stattdessen Cross-Region liest.

• Die DDL und die Erweiterung für ausländische Tabellen werden erst repliziert, nachdem die sekundäre Tabelle angehängt und synchronisiert wurde. Installieren Sie die aurora_analytics Erweiterung und erstellen Sie Fremdtabellen auf der Primärtabelle, nachdem die Sekundärtabelle angeschlossen wurde, sodass sie sich verbreiten.