Limitazioni e considerazioni per le implementazioni blu/green - Amazon Aurora
LimitazioniConsiderazioni

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Limitazioni e considerazioni per le implementazioni blu/green

Le implementazioni blu/green in RDS Amazon richiedono un'attenta considerazione di fattori come gli slot di replica, la gestione delle risorse, il dimensionamento delle istanze e i potenziali impatti sulle prestazioni del database. Le sezioni seguenti forniscono indicazioni per aiutarti a ottimizzare la tua strategia di distribuzione per garantire tempi di inattività minimi, transizioni fluide e una gestione efficace dell'ambiente di database.

Limitazioni per le implementazioni blu/verde

Le seguenti limitazioni si applicano alle implementazioni blu/verde.

Limitazioni generali per le implementazioni blu/verde

Le seguenti limitazioni generali si applicano alle implementazioni blu/verde:

  • Non è possibile interrompere e avviare un cluster che fa parte di una distribuzione blu/verde.

  • Le distribuzioni blu/verde non supportano la gestione delle password degli utenti principali con. AWS Secrets Manager

  • Se si tenta di forzare un backtrack sul cluster DB blu, la distribuzione blu/verde si interrompe e lo switchover viene bloccato.

  • Durante lo switchover, gli ambienti blu e verde non possono avere ETL integrazioni zero con Amazon Redshift. Occorre prima eliminare l'integrazione ed eseguire il passaggio, quindi ricreare l'integrazione.

  • Il pianificatore eventi (parametro event_scheduler) deve essere disabilitato nell'ambiente verde quando si crea un'implementazione blu/verde. Ciò impedisce che si generino eventi nell'ambiente verde e conseguentemente incongruenze.

  • Le politiche di Auto Scaling configurate sul cluster DB blu non vengono copiate nell'ambiente verde. È necessario riconfigurarle dopo lo switchover, indipendentemente dal fatto che siano state inizialmente configurate nell'ambiente blu o verde.

  • Non è possibile modificare un cluster di database decrittografato in un cluster di database crittografato.

  • Non è possibile modificare un cluster di DB blu con una versione del motore superiore rispetto al corrispondente cluster di DB verde.

  • Le risorse nell'ambiente blu e nell'ambiente verde devono trovarsi nello stesso Account AWS.

  • Le implementazioni blu/verde non sono supportate per le seguenti funzionalità:

    • RDSProxy Amazon

    • Repliche di lettura tra regioni diverse

    • Aurora Serverless v1 Cluster database

    • Cluster database che fanno parte di un database globale Aurora

    • AWS CloudFormation

SQLLimitazioni di Aurora My SQL RDS for My blu/green

Le seguenti limitazioni si applicano alle implementazioni SQL blu/green di Aurora My SQL RDS :

  • Il cluster DB di origine non può contenere alcun database denominato. tmp I database con questo nome non verranno copiati nell'ambiente verde.

  • Il cluster di DB blu non può essere una replica binlog esterna.

  • Se il cluster DB di origine con backtrack è abilitato, il cluster DB verde viene creato senza supporto per il backtrack. Questo perché il backtracking non funziona con la replica dei log binari (binlog), necessaria per le implementazioni blu/green. Per ulteriori informazioni, consulta Backtrack di un cluster database Aurora.

  • Le distribuzioni blu/verdi non supportano Driver for My. AWS JDBC SQL Per ulteriori informazioni, consulta Limitazioni note su. GitHub

SQL

  • Le tabelle non registrate non vengono replicate nell'ambiente verde a meno che il rds.logically_replicate_unlogged_tables parametro non sia impostato su nel cluster DB blu. 1 Non modificate il valore di questo parametro dopo aver creato una distribuzione blu/verde per evitare possibili errori di replica su tabelle non registrate.

  • Il cluster di DB blu non può essere una fonte logica (editore) o una replica (sottoscrittore).

  • Se il cluster DB è configurato come server esterno di un'estensione esterna di data wrapper (FDW), è necessario utilizzare il nome dell'endpoint del cluster di anziché gli indirizzi IP. Ciò consente alla configurazione di rimanere funzionale dopo lo switchover.

  • In una distribuzione blu/verde, ogni database richiede uno slot di replica logico. Con l'aumentare del numero di database, il sovraccarico di risorse aumenta e può potenzialmente causare ritardi nella replica, soprattutto se l'istanza DB del cluster non è sufficientemente scalata. L'impatto dipende da fattori quali il carico di lavoro del database e il numero di connessioni.

  • Le distribuzioni blu/verde sono supportate per Babelfish for Aurora Postgre SQL solo per la versione 15.7 e successive 15 versioni e 16.3 e versioni successive 16.

  • Se desideri acquisire i piani di esecuzione nelle repliche di Aurora, devi fornire l'endpoint blu del cluster di database quando chiami la funzione apg_plan_mgmt.create_replica_plan_capture. Ciò garantisce che le acquisizioni dei piani continuino a funzionare dopo lo switchover. Per ulteriori informazioni, consulta Acquisizione dei piani di esecuzione di Aurora SQL Postgre nelle repliche.

  • Le seguenti limitazioni si SQL applicano alle estensioni Postgre:

    • L'pg_partmanestensione deve essere disabilitata nell'ambiente blu quando si crea una distribuzione blu/verde. L'estensione esegue DDL operazioni come CREATE TABLE quelle che interrompono la replica logica dall'ambiente blu all'ambiente verde.

    • L'estensione pg_cron deve rimanere disabilitata su tutti i database verdi dopo la creazione dell'implementazione blu/verde. L'estensione dispone di worker in background che vengono eseguiti come superutente e aggirano l'impostazione di sola lettura dell'ambiente verde, il che potrebbe causare conflitti di replica.

    • L'estensione apg_plan_mgmt deve avere il parametro apg_plan_mgmt.capture_plan_baselines impostato su off in tutti i database verdi per evitare conflitti di chiave primaria se un piano identico viene acquisito nell'ambiente blu. Per ulteriori informazioni, consulta Panoramica sulla gestione del piano di interrogazione di Aurora SQL Postgre.

    • Le estensioni pglogical e pgactive devono essere disabilitate nell'ambiente blu quando si crea un'implementazione blu/verde. Dopo aver convertito l'ambiente verde nel nuovo ambiente di produzione, è possibile abilitare nuovamente le estensioni. Inoltre, il database blu non può essere un abbonato logico di un'istanza esterna.

    • Se utilizzi l'pgAuditestensione, deve rimanere nelle librerie condivise (shared_preload_libraries) nei gruppi di parametri DB personalizzati sia per le istanze DB blu che per quelle verdi. Per ulteriori informazioni, consulta Configurazione dell' pgAudit estensione.

Limitazioni specifiche della replica logica per le distribuzioni blu/verdi

Limitazione Spiegazione
Le istruzioni del linguaggio di definizione dei dati (DDL), come CREATE TABLE eCREATE SCHEMA, non vengono replicate dall'ambiente blu all'ambiente verde.

Se Aurora rileva un DDL cambiamento nell'ambiente blu, i database verdi entrano in uno stato di replica degradato. È necessario eliminare l'implementazione blu/verde e tutti i database verdi, quindi ricrearla.
Le operazioni NEXTVAL sugli oggetti della sequenza non sono sincronizzate tra l'ambiente blu e l'ambiente verde.

Durante lo switchover, Aurora incrementa i valori di sequenza nell'ambiente verde in modo che corrispondano a quelli nell'ambiente blu. Se hai migliaia di sequenze, lo switchover può subire un ritardo.
La creazione o la modifica di oggetti di grandi dimensioni nell'ambiente blu non viene replicata nell'ambiente verde.

Se Aurora rileva la creazione o la modifica di oggetti di grandi dimensioni nell'ambiente blu archiviati nella tabella di pg_largeobject sistema, i database verdi entrano in uno stato di replica degradato. È necessario eliminare l'implementazione blu/verde e tutti i database verdi, quindi ricrearla.

Le viste materializzate non vengono aggiornate automaticamente nell'ambiente verde.

L'aggiornamento delle viste materializzate nell'ambiente blu non le aggiorna nell'ambiente verde. Dopo il passaggio, puoi aggiornarli manualmente utilizzando il comando o pianificare un aggiornamento. REFRESHMATERIALIZEDVIEW

UPDATEe DELETE le operazioni non sono consentite su tabelle che non dispongono di una chiave primaria.

Prima di creare un'implementazione blu/verde, assicurati che tutte le tabelle nel cluster di database abbiano una chiave primaria.

Per ulteriori informazioni, consulta Restrizioni nella documentazione sulla replica SQL logica di Postgre.

Considerazioni sulle implementazioni blu/verde

Amazon RDS monitora le risorse nelle distribuzioni blu/verdi con l'DbiResourceIdausilio di ogni risorsa. DbClusterResourceId Questo ID di risorsa è un identificatore Regione AWS univoco e immutabile della risorsa.

Ciascuno è elencato nella configurazione del database nella RDS console.

Il nome (ID cluster) di una risorsa viene modificato quando effettui lo switchover a un'implementazione blu/verde, ma ogni risorsa mantiene lo stesso ID risorsa. Ad esempio, un identificatore di cluster di database potrebbe essere mycluster nell'ambiente blu. Dopo lo switchover, lo stesso cluster di database potrebbe essere rinominato in mycluster-old1. Tuttavia, l'ID risorsa del cluster di database non viene modificato durante lo switchover. Quindi, quando sostituisci le risorse verdi con le nuove risorse di produzione, le loro risorse IDs non corrispondono alla risorsa blu IDs che era precedentemente in produzione.

Dopo il passaggio a una distribuzione blu/verde, valuta la possibilità di aggiornare la risorsa IDs con quelle delle risorse di produzione appena trasferite per funzionalità e servizi integrati utilizzati con le risorse di produzione. In particolare, considera i seguenti aggiornamenti:

  • Se esegui il filtraggio utilizzando la risorsa RDS API andIDs, modifica la risorsa IDs utilizzata nel filtraggio dopo il passaggio.

  • Se utilizzate risorse CloudTrail per il controllo, impostate i consumatori della risorsa in modo che tengano traccia della nuova risorsa dopo il CloudTrail passaggio al digitale. IDs Per ulteriori informazioni, consulta Monitoraggio delle chiamate API Aurora in AWS CloudTrail.

  • Se utilizzi i flussi di attività del database per le risorse dell'ambiente blu, regola l'applicazione per monitorare gli eventi del database per il nuovo flusso dopo lo switchover. Per ulteriori informazioni, consulta Regioni supportate e motori Aurora DB per i flussi di attività del database.

  • Se utilizzi Performance InsightsAPI, imposta la risorsa IDs nelle chiamate alla fase API successiva allo switchover. Per ulteriori informazioni, consulta Monitoraggio del carico del DB con Performance Insights su Amazon Aurora.

    Dopo lo switchover è possibile monitorare un database con lo stesso nome, ma non contiene i dati precedenti allo lo switchover.

  • Se utilizzi la risorsa IDs nelle IAM politiche, assicurati di aggiungere la risorsa IDs delle risorse appena trasferite quando necessario. Per ulteriori informazioni, consulta Gestione delle identità e degli accessi per Amazon Aurora.

  • Se hai IAM ruoli associati all', assicurati di riassociarli dopo lo switchover. I ruoli allegati non vengono copiati automaticamente nell'ambiente verde.

  • Se esegui l'autenticazione nel cluster di DB utilizzando l'autenticazione del IAM database, assicurati che la IAM policy utilizzata per l'accesso al database contenga sia il database blu che quello verde elencati sotto l'Resourceelemento della policy. Ciò è necessario per connettersi al database verde dopo il passaggio. Per ulteriori informazioni, consulta Creazione e utilizzo di una policy IAM per l'accesso al database IAM.

  • Se desideri ripristinare uno snapshot di cluster di database manuale per un cluster di database che faceva parte di un'implementazione blu/verde, assicurati di ripristinare lo snapshot del cluster di database corretto esaminando l'ora in cui è stato creato. Per ulteriori informazioni, consulta Ripristino da uno snapshot cluster database.

  • Dopo il passaggio, le attività di replica AWS Database Migration Service (AWS DMS) non possono riprendere perché il checkpoint dall'ambiente blu non è valido nell'ambiente verde. È necessario ricreare l'DMSattività con un nuovo checkpoint per continuare la replica.

  • Amazon Aurora crea l'ambiente verde clonando il volume di archiviazione di Aurora sottostante nell'ambiente blu. Il volume del cluster verde memorizza solo le modifiche incrementali apportate all'ambiente verde. Se elimini il cluster di database nell'ambiente blu, la dimensione del volume di archiviazione di Aurora sottostante nell'ambiente verde aumenta fino a raggiungere la dimensione completa. Per ulteriori informazioni, consulta Clonazione di un volume per un cluster di database Amazon Aurora.

  • Quando aggiungi un'istanza database al cluster di database nell'ambiente verde di un'implementazione blu/verde, la nuova istanza database non sostituisce un'istanza database nell'ambiente blu al momento dello switchover. Tuttavia, la nuova istanza database viene mantenuta nel cluster di database e diventa un'istanza database nel nuovo ambiente di produzione.

  • Quando elimini un'istanza DB nel cluster DB nell'ambiente verde di una blue/green deployment, you can't create a new DB instance to replace it in the blue/green distribuzione.

    Se crei una nuova istanza DB con lo stesso nome e ARN dell'istanza DB eliminata, ne ha un'altraDbiResourceId, quindi non fa parte dell'ambiente verde.

    Se elimini un'istanza database nel cluster di database nell'ambiente verde, si verifica il seguente comportamento:

    • Se l'istanza database con lo stesso nome esiste nell'ambiente blu, non verrà eseguito lo switchover all'istanza database dell'ambiente verde. Questa istanza database non verrà rinominata aggiungendo -oldn al suo nome.

    • Qualsiasi applicazione che punti all'istanza database nell'ambiente blu continua a utilizzare la stessa istanza database dopo lo switchover.