Utilizzo di tabelle esterne con Aurora Global Database

Aurora Global Database supporta l'esecuzione di query analitiche con configurazione per regione. Questa sezione descrive come configurare le query analitiche tra le regioni, quali risorse vengono replicate automaticamente e come pianificare gli scenari di disaster recovery.

Utilizzo di aurora_analytics con un database globale

Una tabella esterna è una definizione di tabella PostgreSQL che punta ai dati di Apache Iceberg o Parquet in Amazon S3, Amazon S3 Tables o. AWS Glue Data Catalog Nessun dato viene copiato in Aurora. Solo i seguenti elementi vengono replicati dal cluster DB primario a ciascun cluster DB secondario:

• L'installazione dell'aurora_analyticsestensione

• Definizioni di tabelle esterne (DDL)

Quanto segue non viene replicato e deve essere fornito indipendentemente in ogni regione che contiene un cluster DB secondario:

• L'associazione dei ruoli IAM al cluster DB

• La policy IAM che concede l'accesso ad Amazon S3 AWS Glue o Amazon S3 Tables

• Rete VPC (endpoint o NAT) utilizzata per raggiungere tali servizi

Configurazione su un database globale

Fase 1: Crea la policy e il ruolo IAM in ogni regione

L'associazione di ruoli IAM non si replica tra i cluster DB primari e secondari. È necessario creare e collegare un ruolo IAM con il nome della AuroraAnalytics funzionalità in ogni regione che contiene un cluster DB primario o secondario.

1. Crea una policy IAM che garantisca l'accesso in lettura ai tuoi dati. Le autorizzazioni richieste dipendono dal formato dei dati. Per ulteriori informazioni, consulta Riferimento alle politiche IAM.

2. Crea un ruolo IAM considerato affidabile rds.amazonaws.com e allega la policy.

3. Associa il ruolo al cluster DB di quella regione:

   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. Attendi che lo stato del ruolo venga visualizzato come Attivo.

Nota

Immediatamente dopo l'associazione di un ruolo (o dopo l'avvio o la promozione di un'istanza), le query su tabelle esterne potrebbero restituire brevemente l'errore:credential to access AWS service is unavailable. Attendi che lo stato del ruolo sia Attivo prima di eseguire query su tabelle esterne.

Fase 2: Configurare la rete in ogni regione

Inoltre, la configurazione VPC non viene replicata. Nel VPC per ogni cluster DB (primario e secondario), fornisci un percorso di rete ai servizi richiesti in modo che il cluster DB possa raggiungere i dati della tabella esterna per risolvere le query. Assicurati che la configurazione di rete del cluster di ogni secondario consenta di raggiungere la regione della tabella esterna.

Endpoint VPC richiesti per ogni regione

Servizio	Tipo di endpoint	Obbligatorio per
Amazon S3 (com.amazonaws.<region>.s3)	Gateway	Accesso a tutti i dati di Amazon S3 e Amazon S3 Tables
AWS Glue (com.amazonaws.<region>.glue)	Interfaccia	AWS Glue Data Catalog accesso (tabelle Iceberg)
AWS STS (com.amazonaws.<region>.sts)	Interfaccia	recupero delle credenziali dei ruoli IAM

Per gli endpoint AWS Glue e di AWS STS interfaccia, abilita il DNS privato e consenti il protocollo TCP 443 in entrata dal tuo VPC CIDR.

Passaggio 3: installa l'estensione sul primario

Connect all'istanza Writer DB nel cluster DB primario e installa l'estensione in ogni database in cui intendi creare tabelle esterne:

CREATE EXTENSION aurora_analytics;

L'estensione si replica automaticamente su ogni cluster DB secondario.

Fase 4: Creare tabelle esterne sul primario

Sull'istanza Writer DB nel cluster DB primario, crea tabelle esterne che puntano ai tuoi dati:

-- 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 replica il DDL su ogni cluster DB secondario, dove le tabelle esterne sono disponibili per l'interrogazione.

Passaggio 5: verifica sul secondario

Connect a un cluster DB secondario e conferma la replica e l'accesso in lettura:

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

Blocco regionale delle tabelle esterne

Quando crei una tabella esterna, i relativi dati location Region vengono archiviati nella definizione della tabella e replicati in ogni cluster DB del database globale. Ogni cluster DB legge dalla stessa posizione.

Ciò implica:

• Ogni cluster DB secondario legge i dati delle tabelle esterne dalla regione specificata nella definizione della tabella.

• Se tale regione è diversa dalla regione secondaria, le letture sono interregionali, il che comporta costi e latenza per il trasferimento dei dati.

• Il ruolo IAM e il permesso di rete di ogni unità secondaria raggiungono la regione della tabella esterna.

Nota

I punti di Multi-Region accesso Amazon S3 (MRAP) non sono supportati come posizione di tabella esterna. Aurora PostgreSQL accetta solo URIs3://, Table AWS Glue ARN e Amazon S3 Tables ARN nell'opzione. location Gli ARN MRAP e i nomi host MRAP non sono validi per l'opzione. location

Linee guida generali per la preparazione al DR

Completa la configurazione per regione nei passaggi 1—2 per il cluster DB secondario, quindi decidi in che modo il cluster DB accederà ai dati delle tabelle esterne:

• Accetta letture interregionali: questo approccio è adatto solo per scenari di switchover pianificati in cui la regione originale è integra.

• Pre-stage una Region-local copia: utilizza Amazon S3 Cross-Region Replication in modo che le query analitiche possano essere lette localmente anche se la regione originale non è disponibile. Prepara ALTER FOREIGN TABLE ... OPTIONS (SET ...) le istruzioni per aggiornare le posizioni delle tabelle esterne in modo che rimandino alla copia. Region-local

Nota

La cache di lettura su disco non viene mantenuta o trasferita quando si verifica uno switchover o un failover. Le prime query dopo l'evento leggono i dati da Amazon S3 e vengono eseguite con una latenza più elevata fino al riscaldamento della cache.

Gestione dello switchover e del failover

Durante uno switchover o un failover di Aurora Global Database, le query di tabelle esterne hanno una dipendenza aggiuntiva rispetto alle connessioni client di database standard: devono raggiungere Amazon S3 e AWS STS nella regione indicata da ciascuna AWS Glue tabella esterna.

Switchover globale del database

Sia il cluster DB primario che quello secondario sono integri al momento del passaggio. Dopo che il nuovo cluster DB primario diventa disponibile, le query continuano a essere lette dalla regione denominata in ogni tabella esterna. Se tale regione è diversa dalla regione del nuovo scrittore, le letture sono interregionali e comportano costi di trasferimento dei dati e latenza. Per evitare la latenza di lettura tra regioni diverse, esegui le ALTER FOREIGN TABLE ... OPTIONS (SET ...) istruzioni preparate per riindirizzare le tabelle esterne su una copia. Region-local

Ripresa delle operazioni dopo uno switchover

1. Consenti ai client di riconnettersi all'endpoint writer del nuovo cluster DB primario.

2. Attendi che lo stato del ruolo IAM sia attivo. Esegui una query di test su una tabella esterna (ad esempio,SELECT count(*) FROM ft_orders) con la logica di ripetizione per confermare che le query di analisi siano operative.

3. Se usi una Region-local copia, esegui le ALTER istruzioni preparate sul nuovo cluster DB primario per aggiornare le posizioni delle tabelle esterne:

   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');

Nota

ALTER FOREIGN TABLE ... OPTIONS (SET ...)è una modifica dei soli metadati del catalogo. Viene completata immediatamente senza spostamento dei dati. Basta un breve ACCESS EXCLUSIVE blocco su quell'unica tabella straniera. Pertanto, viene bloccato da qualsiasi interrogazione in corso sulla stessa tabella.

Failover globale del database

La regione originale potrebbe essere danneggiata o irraggiungibile. Se una tabella esterna nomina la regione danneggiata, le interrogazioni su di essa presentano un'elevata latenza o falliscono con errori di timeout fino a quando la regione non viene ripristinata o non si riindirizza la tabella esterna ai dati in una regione integra. Se hai preimpostato una Region-local copia, esegui le ALTER FOREIGN TABLE ... OPTIONS (SET region ...) istruzioni preparate per indirizzare le tabelle esterne verso la copia. Region-local

Ritorno alla regione principale originale

Quando la regione primaria originale diventa disponibile, Aurora la aggiunge automaticamente al database globale come cluster DB secondario. Qualsiasi ALTER FOREIGN TABLE modifica apportata durante lo switchover o il failover viene replicata su di esso tramite la replica globale. Per ripristinare la regione primaria originale, eseguite uno switchover. Una volta completato lo switchover, stabilite se ripristinare le posizioni delle tabelle esterne in modo che puntino ai dati nella regione primaria ripristinata.

Messaggi di errore su un database globale

Dopo uno switchover o un failover, le query nella nuova regione primaria possono avere esito negativo con gli stessi errori di associazione di ruoli IAM, autorizzazione IAM e rete che riguardano qualsiasi regione che esegue un cluster DB secondario. Questi errori e le relative risoluzioni sono trattati nella sezione Switchover e failover di Global Database. Monitoraggio e risoluzione dei problemi I prerequisiti devono essere soddisfatti in ogni regione secondaria, poiché l'associazione di ruoli IAM, la policy IAM e la rete VPC non si replicano.

• Le tabelle esterne location e region sono un'unica definizione replicata senza alcun override per regione. Entrambi i cluster non possono contenere regioni diverse per la stessa tabella.

• I punti di Multi-Region accesso Amazon S3 e gli ARN dei punti di accesso Amazon S3 non sono supportati come posizioni di tabelle esterne.

• Gli endpoint gateway VPC sono regionali e non possono raggiungere Amazon S3 di un'altra regione. Un percorso di rete interregionale richiede l' NAT/internet uscita o il Transit Gateway.

• Dopo uno switchover, l'aggiornamento della posizione di una tabella esterna nella regione del nuovo cluster DB primario fa sì che il precedente cluster DB primario legga invece Cross-region.

• La tabella esterna DDL e l'estensione si replicano solo dopo che la tabella secondaria è stata collegata e sincronizzata. Installa l'aurora_analyticsestensione e crea tabelle esterne sulla principale dopo la connessione della secondaria in modo che si propaghino.