Limitazioni e considerazioni per le distribuzioni di Amazon Aurora blue/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 distribuzioni di Amazon Aurora blue/green

Le implementazioni blu/verde in Amazon RDS richiedono un’attenta considerazione dei fattori quali 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 ottimizzare la strategia di implementazione e garantire un tempo di inattività minimo, transizioni fluide e una gestione efficace dell’ambiente di database.

blue/green Limitazioni per le distribuzioni

Le seguenti limitazioni si applicano alle blue/green distribuzioni.

Limitazioni generali per le implementazioni blu/verde

Le seguenti limitazioni generali si applicano alle blue/green distribuzioni:

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

  • Le implementazioni blu/verde non supportano la gestione delle password degli utenti master con Gestione dei segreti AWS.

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

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

  • L'Event Scheduler (event_schedulerparametro) deve essere disabilitato nell'ambiente verde quando si crea una distribuzione. blue/green Ciò impedisce che si generino eventi nell'ambiente verde e conseguentemente incongruenze.

  • Le policy di dimensionamento automatico configurate sul cluster di database 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. Inoltre, non è possibile modificare un cluster di database crittografato in un cluster di database decrittografato.

  • Non è possibile modificare un cluster di database dell’ambiente blu con una versione successiva del motore rispetto al cluster di database dell’ambiente 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à:

    • Server proxy per Amazon RDS

    • Repliche di lettura tra regioni diverse

    • Cluster di database Aurora Serverless v1

    • Cluster database che fanno parte di un database globale Aurora

    • CloudFormation

Aurora MySQL for MySQL: limitazioni per le implementazioni blue/green

blue/green

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

  • Il cluster di database dell’ambiente blu non può essere una replica di log binari esterna.

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

  • Le distribuzioni blu/green non supportano il driver AWS JDBC per MySQL. Per ulteriori informazioni, consulta Limitazioni note su. GitHub

Le seguenti limitazioni si applicano alle implementazioni blu/verde di Aurora PostgreSQL blue/green deployments.

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

  • Il cluster di database blu non può essere un’origine logica (publisher) o una replica (subscriber).

  • Se il cluster di database blu è configurato come server esterno di un’estensione FDW (Foreign Data Wrapper), è necessario utilizzare il nome dell’endpoint del cluster anziché gli indirizzi IP. Ciò consente alla configurazione di rimanere funzionale dopo lo switchover.

  • In una blue/green distribuzione, ogni database richiede uno slot di replica logico. Con l’aumentare del numero di database, incrementa il sovraccarico delle risorse che può potenzialmente causare ritardi nella replica, soprattutto se il dimensionamento del cluster di database non è sufficiente. L’impatto dipende da fattori quali il carico di lavoro del database e il numero di connessioni. Per mitigare questo problema, è possibile considerare la possibilità di aumentare verticalmente la classe dell’istanza database o di ridurre il numero di database del cluster.

  • Le implementazioni blu/verde sono supportate in Babelfish per Aurora PostgreSQL solo per la versione 15.7 e le versioni successive alla 15 e per la versione 16.3 e le versioni successive alla 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 Aurora PostgreSQL nelle repliche.

  • Il processo di applicazione della replica logica nell’ambiente verde è a thread singolo. Se l’ambiente blu genera un volume elevato di traffico di scrittura, l’ambiente verde potrebbe non essere in grado di tenere il passo. Ciò può causare ritardi o errori di replica, in particolare per i carichi di lavoro che producono un throughput di scrittura elevato. È necessario testare accuratamente i carichi di lavoro. Per gli scenari che richiedono aggiornamenti della versione principale e la gestione di carichi di lavoro di scrittura a volume elevato, si possono prendere in considerazione approcci alternativi come l’utilizzo di AWS Database Migration Service (AWS DMS) o la replica logica autogestita.

  • La creazione di nuove partizioni sulle tabelle partizionate non è supportata durante le implementazioni blu/verde per Aurora. La creazione di nuove partizioni implica operazioni DDL (Data Definition Language) come CREATE TABLE, che non vengono replicate dall’ambiente blu nell’ambiente verde. Tuttavia, le tabelle partizionate esistenti e i relativi dati verranno replicati nell’ambiente verde.

  • Alle estensioni PostgreSQL si applicano le seguenti limitazioni:

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

    • L'pg_cronestensione deve rimanere disabilitata su tutti i database verdi dopo la creazione della blue/green distribuzione. 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 della gestione del piano di query per Aurora PostgreSQL.

    • Le pgactive estensioni pglogical e devono essere disabilitate nell'ambiente blu quando si crea una blue/green distribuzione. Dopo aver eseguito lo switchover dell’ambiente verde nel nuovo ambiente di produzione, si possono abilitare nuovamente le estensioni. Inoltre, il database blu non può essere un abbonato logico di un'istanza esterna.

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

Limitazioni specifiche della replica logica per le distribuzioni blue/green

La tabella seguente descrive le limitazioni della replica logica che si applicano alle implementazioni blu/verde per Aurora PostgreSQL. Per ulteriori informazioni, consulta Restrictions nella documentazione della replica logica di PostgreSQL.

Limitazione Spiegazione
Le istruzioni DDL (Data Definition Language), come CREATE TABLE e CREATE SCHEMA, non vengono replicate dall'ambiente blu nell'ambiente verde.

Se Aurora rileva una modifica DDL nell'ambiente blu, i database verdi entrano nello stato di replica degradata. È necessario eliminare la blue/green distribuzione e tutti i database ecologici, quindi ricrearli.
Le istruzioni DCL (Data Control Language), come GRANT e REVOKE, non vengono replicate dall’ambiente blu nell’ambiente verde.

Se Aurora rileva un tentativo di eseguire un’istruzione DCL nell’ambiente blu, verrà visualizzato un messaggio di avviso. Non è disponibile alcuna configurazione o API per modificare questo comportamento, poiché si tratta di una limitazione del processo di blue/green distribuzione.
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.
Gli oggetti di grandi dimensioni nell’ambiente blu non vengono replicati nell’ambiente verde. Ciò include sia gli oggetti di grandi dimensioni esistenti che gli oggetti di grandi dimensioni appena creati o modificati durante il processo di blue/green distribuzione.

Se Aurora rileva la creazione o la modifica di oggetti di grandi dimensioni nell'ambiente blu archiviati nella tabella di sistema pg_largeobject, i database verdi entrano nello stato di replica degradata. È necessario eliminare la blue/green distribuzione e tutti i database verdi, quindi ricrearli.

L’aggiornamento delle viste materializzate interrompe la replica.

L’aggiornamento delle viste materializzate nell’ambiente blu interrompe la replica nell’ambiente verde. È consigliabile evitare di aggiornare le viste materializzate nell’ambiente blu. Dopo uno switchover, è possibile aggiornarle manualmente utilizzando il comando REFRESH MATERIALIZED VIEW o pianificare un aggiornamento.

Le operazioni UPDATE e DELETE non sono consentite nelle tabelle che non dispongono di una chiave primaria.

Prima di creare una blue/green distribuzione, assicurati che tutte le tabelle abbiano una chiave o un utilizzo REPLICA IDENTITY FULL primari. Tuttavia, REPLICA IDENTITY FULL si utilizza solo se non esiste una chiave primaria o univoca, poiché influisce sulle prestazioni di replica. Per ulteriori informazioni, consultare la documentazione di PostgreSQL.

Considerazioni per le distribuzioni blue/green

Amazon RDS tiene traccia delle risorse nelle blue/green distribuzioni con l'ausilio DbClusterResourceId di DbiResourceId ogni risorsa. Questo ID di risorsa è un identificatore Regione AWS univoco e immutabile per la risorsa.

L’ID della risorsa è separato dall’ID del cluster database. Ciascuno di essi è elencato nella configurazione del database nella console RDS.

Il nome (ID del cluster) di una risorsa cambia quando si passa a una blue/green distribuzione, ma ogni risorsa mantiene lo stesso ID di 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. Pertanto, quando si sostituiscono le risorse verdi con le nuove risorse di produzione, le relative risorse IDs non corrispondono alla risorsa IDs blu precedentemente in produzione.

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

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

  • Se le utilizzate CloudTrail per il controllo delle risorse, 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 chamate API di Amazon 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 e motori di database Aurora supportati per flussi di attività del database.

  • Se utilizzi l'API Performance Insights, modifica la risorsa IDs nelle chiamate all'API dopo lo switchover. Per ulteriori informazioni, consulta Monitoraggio del carico 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 una risorsa IDs nelle policy IAM, assicurati di aggiungere la risorsa IDs delle risorse appena trasferite quando necessario. Per ulteriori informazioni, consulta Gestione accessi e identità per Amazon Aurora.

  • Se sono disponibili ruoli IAM associati al cluster di database, è necessario riassociarli dopo lo switchover. I ruoli collegati non vengono copiati automaticamente nell’ambiente verde.

  • Se si esegue l'autenticazione nel cluster database utilizzando l'autenticazione del database IAM, assicurarsi che la policy IAM utilizzata per l'accesso al database contenga sia i database blu che quelli verdi elencati sotto l'elemento Resource 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 manuale del cluster DB per un cluster DB che faceva parte di una blue/green distribuzione, assicurati di ripristinare lo snapshot corretto del cluster DB esaminando l'ora in cui è stata scattata la snapshot. 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’attività DMS 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 si elimina 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 database con lo stesso nome e nome della risorsa Amazon (ARN) dell'istanza database eliminata, ha un DbiResourceId diverso e 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.

  • Se si utilizzano i tag delle risorse per il controllo degli accessi o la gestione operativa, è necessario comprendere che le modifiche ai tag non vengono sincronizzate tra ambienti blu e verdi fino al passaggio. Quando crei una blue/green distribuzione, i tag dall'ambiente blu vengono copiati nell'ambiente verde. Dopo la creazione, tutte le modifiche ai tag apportate a entrambi gli ambienti non vengono sincronizzate automaticamente. Durante lo switchover, i tag di ambiente blu sostituiscono tutti i tag nell'ambiente verde. Applica tutti i tag necessari all'ambiente blu prima di creare la blue/green distribuzione o riapplica i tag richiesti al nuovo ambiente di produzione dopo il passaggio. Per ulteriori informazioni sui tag, consulta Tag delle risorse Amazon Aurora e Amazon RDS.