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à.
# Utilizzo di Amazon RDS Blue/Green Aurora Deployments per gli aggiornamenti del database
Una blue/green distribuzione copia un ambiente di database di produzione in un ambiente di staging separato e sincronizzato. Utilizzando Amazon RDS Blue/Green Aurora Deployments, puoi apportare modifiche al database nell'ambiente di staging senza influire sull'ambiente di produzione. Ad esempio, è possibile aggiornare la versione principale o secondaria del motore di database o modificare i parametri del database nell’ambiente di staging. Quando è tutto pronto, è possibile promuovere l’ambiente di staging nel nuovo ambiente di database di produzione, con un tempo di inattività in genere inferiore al minuto.
**Nota**
Attualmente, Blue/Green le implementazioni sono supportate solo per RDS per MariaDB, RDS per MySQL e RDS per PostgreSQL. *Per la disponibilità di Amazon Aurora, consulta [Using Amazon Blue/Green Aurora Deployments per gli aggiornamenti del database nella](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) Amazon Aurora User Guide.*
**Topics**
+ [Panoramica delle implementazioni di Amazon RDS Blue/Green](blue-green-deployments-overview.md)
+ [Creazione di una blue/green distribuzione in Amazon RDS](blue-green-deployments-creating.md)
+ [Visualizzazione di un’implementazione blu/verde in Amazon RDS](blue-green-deployments-viewing.md)
+ [Cambiare una blue/green distribuzione in Amazon RDS](blue-green-deployments-switching.md)
+ [](blue-green-deployments-deleting.md)
# Panoramica delle implementazioni di Amazon RDS Blue/Green
Utilizzando Amazon RDS Blue/Green Aurora Deployments, puoi apportare e testare modifiche al database prima di implementarle in un ambiente di produzione. Un'*implementazione blu/verde* crea un ambiente di gestione temporanea che copia l'ambiente di produzione. In un'implementazione blu/verde, l'*ambiente blu* è l'ambiente di produzione corrente. L’*ambiente verde* è l’ambiente di staging e rimane sincronizzato con l’attuale ambiente di produzione.
È possibile apportare modifiche alle istanze database RDS nell'ambiente verde senza influire sui carichi di lavoro di produzione. Ad esempio, è possibile aggiornare la versione principale o secondaria del motore di database, aggiornare la configurazione del file system sottostante o modificare i parametri di database nell'ambiente di gestione temporanea. È possibile testare le modifiche nell'ambiente verde. Quando è tutto pronto, è possibile eseguire lo *switchover* degli ambienti per passare l’ambiente verde nel nuovo ambiente di produzione. Lo switchover richiede in genere meno di un minuto senza perdita di dati e senza la necessità di modificare l'applicazione.
Poiché è una copia della topologia dell'ambiente di produzione, l'ambiente verde include le funzionalità utilizzate dall'istanza database. Queste funzionalità comprendono le repliche di lettura, la configurazione dell'archiviazione, gli snapshot del database, i backup automatici, approfondimenti sulle prestazioni e il monitoraggio avanzato. Se l'istanza database blu è un'implementazione di istanza database multi-AZ, anche l'istanza database verde è un'implementazione di istanza database multi-AZ.
**Nota**
Attualmente, blue/green le implementazioni sono supportate solo per RDS per MariaDB, RDS per MySQL e RDS per PostgreSQL. Per la disponibilità di Amazon Aurora, consulta [Overview of Amazon Aurora Blue/Green Deployments](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html) nella *Guida per l’utente di Amazon Aurora*.
In determinate condizioni, RDS per PostgreSQL utilizza la replica logica anziché la replica fisica per mantenere l’ambiente verde sincronizzato con l’ambiente blu. Per ulteriori informazioni, consulta [Metodi di replica PostgreSQL per le distribuzioni blue/green](blue-green-deployments-replication-type.md).
**Topics**
+ [Disponibilità di regioni e versioni](#blue-green-deployments-region-version-availability)
+ [Vantaggi dell'utilizzo di Amazon RDS Blue/Green Deployments](#blue-green-deployments-benefits)
+ [Flusso di lavoro di una distribuzione blue/green](#blue-green-deployments-major-steps)
+ [Autorizzazione dell'accesso alle operazioni di distribuzione di Amazon RDS](blue-green-deployments-authorizing-access.md)
+ [Limitazioni e considerazioni per le distribuzioni di Amazon RDS Amazon blue/green](blue-green-deployments-considerations.md)
+ [Best practice per le implementazioni di Amazon RDS blue/green](blue-green-deployments-best-practices.md)
## Disponibilità di regioni e versioni
Il supporto varia a seconda delle versioni specifiche di ciascun motore di database e a seconda delle Regioni AWS. Per ulteriori informazioni, consulta [Regioni e motori DB supportati per le distribuzioni di Amazon RDS Blue/Green](Concepts.RDS_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md).
## Vantaggi dell'utilizzo di Amazon RDS Blue/Green Deployments
Utilizzando Amazon RDS Blue/Green Deployments, puoi rimanere aggiornato sulle patch di sicurezza, migliorare le prestazioni del database e adottare nuove funzionalità di database con tempi di inattività brevi e prevedibili. Blue/green le implementazioni riducono i rischi e i tempi di inattività per gli aggiornamenti dei database, ad esempio gli aggiornamenti principali o secondari delle versioni del motore.
Le implementazioni blu/verde offrono i seguenti vantaggi:
+ Crea facilmente un ambiente di gestione temporanea pronto per la produzione.
+ Replica automaticamente le modifiche del database dall'ambiente di produzione all'ambiente di gestione temporanea.
+ Esegui il test delle modifiche del database in un ambiente di gestione temporanea sicuro, senza influire sull'ambiente di produzione.
+ Rimani aggiornato con le patch del database e gli aggiornamenti di sistema.
+ Implementa ed esegui il test delle nuove funzionalità del database.
+ Esegui lo switchover dell'ambiente di gestione temporanea in un nuovo ambiente di produzione senza modificare l'applicazione.
+ Esegui lo switchover in sicurezza usando i guardrail di switchover integrati.
+ Elimina la perdita di dati durante lo switchover.
+ Esegui lo switchover rapidamente, in genere in meno di un minuto a seconda del carico di lavoro.
## Flusso di lavoro di una distribuzione blue/green
Completa i seguenti passaggi principali quando utilizzi una blue/green distribuzione per gli aggiornamenti del database.
1. Identifica un ambiente di produzione che richieda aggiornamenti.
Ad esempio, l'ambiente di produzione in questa immagine ha un'implementazione di istanza database multi-AZ (mydb1) e una replica di lettura (mydb2).
![\[Ambiente di produzione (blu) in una blue/green distribuzione\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment-blue-environment.png)
1. Crea la blue/green distribuzione. Per istruzioni, consulta [Creazione di una blue/green distribuzione in Amazon RDS ](blue-green-deployments-creating.md).
L'immagine seguente mostra un esempio di blue/green implementazione dell'ambiente di produzione a partire dalla fase 1. Durante la creazione della blue/green distribuzione, RDS copia la topologia e la configurazione complete dell'istanza DB principale per creare l'ambiente ecologico. I nomi delle istanze database copiati vengono aggiunti con `-green-random-characters`. L'ambiente di staging nell'immagine contiene una distribuzione di istanze DB Multi-AZ (mydb1-green-**abc123**) e una replica di lettura (mydb2-green-). **abc123**
![\[Implementazione blu/verde\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment.png)
Quando si crea la blue/green distribuzione, è possibile aggiornare la versione del motore DB e specificare un gruppo di parametri DB diverso per le istanze DB nell'ambiente verde. RDS configura anche la replica dall'istanza database primaria dell'ambiente blu all'istanza database primaria dell'ambiente verde.
Dopo aver creato la blue/green distribuzione, l'istanza DB nell'ambiente verde è di sola lettura per impostazione predefinita.
1. Se necessario, apporta ulteriori modifiche all'ambiente di gestione temporanea. Ad esempio, è possibile modificare la classe di istanza database utilizzata da una o più istanze database nell’ambiente verde.
Per ulteriori informazioni sulla modifica di un’istanza di database, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md).
1. Esegui il test dell'ambiente di gestione temporanea.
Durante i test, ti consigliamo di mantenere i database in un ambiente verde di sola lettura. Abilita le operazioni di scrittura nell’ambiente verde con cautela perché possono causare conflitti di replica nell’ambiente verde. Possono inoltre generare dati non previsti nei database di produzione dopo lo switchover. Per abilitare le operazioni di scrittura per RDS per MySQL, imposta il parametro `read_only` su `1` e attendi la sincronizzazione del gruppo di parametri. Poiché `read_only` è un parametro dinamico, non è necessario il riavvio. Una volta sincronizzato, modifica `read_only` da `1` a `0`. Per le implementazioni RDS per PostgreSQL che utilizzano la replica logica, imposta il parametro `default_transaction_read_only` su `off` a livello di sessione. Se si utilizza la replica fisica, non è possibile abilitare le operazioni di scrittura nell’ambiente verde.
1. Quando è tutto pronto, è possibile eseguire lo switchover per passare l’ambiente di staging come nuovo ambiente di produzione. Per istruzioni, consulta [Cambiare una blue/green distribuzione in Amazon RDS ](blue-green-deployments-switching.md).
Lo switchover comporta tempi di inattività. I tempi di inattività sono in genere inferiori al minuto, ma possono essere più lunghi a seconda del carico di lavoro.
L'immagine seguente mostra le istanze database dopo lo switchover.
![\[Istanze DB dopo il passaggio a una distribuzione blue/green\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment-switchover.png)
Dopo lo switchover, le istanze database che si trovavano nell'ambiente verde diventano le nuove istanze database di produzione. I nomi e gli endpoint dell’ambiente di produzione corrente vengono assegnati all’ambiente di produzione appena sottoposto allo switchover e non sono richieste modifiche all’applicazione. Di conseguenza, il traffico di produzione ora viene indirizzato al nuovo ambiente di produzione. Le istanze database nell'ambiente blu precedente vengono rinominate aggiungendo `-oldn` al nome corrente, dove `n` è un numero. Ad esempio, supponi che il nome dell'istanza database nell'ambiente blu sia `mydb1`. Dopo lo switchover, il nome dell’istanza database diventa `mydb1-old1`.
Nell'esempio dell'immagine, durante lo switchover si verificano le seguenti modifiche:
+ L'implementazione dell'istanza database multi-AZ dell'ambiente verde denominata `mydb1-green-abc123` diventa l'implementazione dell'istanza database multi-AZ di produzione denominata `mydb1`.
+ La replica di lettura dell'ambiente verde denominata `mydb2-green-abc123` diventa la replica di lettura di produzione `mydb2`.
+ L'implementazione dell'istanza database multi-AZ denominata `mydb1` diventa `mydb1-old1`.
+ La replica di lettura dell'ambiente blu denominata `mydb2` diventa `mydb2-old1`.
1. Se non hai più bisogno di una blue/green distribuzione, puoi eliminarla. Per istruzioni, consulta [](blue-green-deployments-deleting.md).
Dopo lo switchover, l'ambiente di produzione precedente non viene eliminato, quindi è possibile utilizzarlo per i test di regressione, se necessario.
# Autorizzazione dell'accesso alle operazioni di distribuzione di Amazon RDS
Gli utenti devono disporre delle autorizzazioni necessarie per eseguire operazioni relative alle implementazioni blu/verde. Puoi creare le policy IAM che concedono a utenti e ruoli l'autorizzazione per eseguire operazioni API specifiche sulle risorse indicate di cui hanno bisogno. Puoi quindi collegare tali policy ai ruoli o ai set di autorizzazioni IAM che richiedono le autorizzazioni. Per ulteriori informazioni, consulta [Gestione accessi e identità per Amazon RDS](UsingWithRDS.IAM.md).
L'utente che crea una blue/green distribuzione deve disporre delle autorizzazioni per eseguire le seguenti operazioni RDS:
+ `rds:CreateBlueGreenDeployment`
+ `rds:AddTagsToResource`
+ `rds:CreateDBInstanceReadReplica`
L'utente che passa a una blue/green distribuzione deve disporre delle autorizzazioni per eseguire le seguenti operazioni RDS:
+ `rds:SwitchoverBlueGreenDeployment`
+ `rds:ModifyDBInstance`
+ `rds:PromoteReadReplica`
+ `rds:DeleteBlueGreenDeployment`
+ `rds:DeleteDBInstance`
Amazon RDS alloca e modifica le risorse nell’ambiente di staging per conto dell’utente. Queste risorse includono istanze database che utilizzano una convenzione di denominazione definita internamente. Pertanto, le policy IAM allegate non possono contenere modelli di nomi di risorse parziali come `my-db-prefix-*`. Solo i caratteri jolly (\$1) sono supportati. In generale, è consigliabile utilizzare tag di risorsa e altri attributi supportati per controllare l’accesso a queste risorse, anziché i caratteri jolly. Per ulteriori informazioni, consulta [Operazioni, risorse e chiavi di condizione per Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html).
# Limitazioni e considerazioni per le distribuzioni di Amazon RDS Amazon 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.
**Topics**
+ [blue/green Limitazioni per le distribuzioni](#blue-green-deployments-limitations)
+ [Considerazioni per le implementazioni blue/green](#blue-green-deployments-consider)
## blue/green Limitazioni per le distribuzioni
Le seguenti limitazioni si applicano alle blue/green distribuzioni.
**Topics**
+ [Limitazioni generali per le distribuzioni blue/green](#blue-green-deployments-limitations-general)
+ [: limitazioni per le implementazioni blue/green](#blue-green-deployments-limitations-mysql)
+ [Limitazioni di RDS per PostgreSQL per le implementazioni con replica fisica blue/green](#blue-green-deployments-limitations-postgres-physical)
+ [Limitazioni di logica blue/green](#blue-green-deployments-limitations-postgres-logical)
### Limitazioni generali per le distribuzioni blue/green
Le seguenti limitazioni generali si applicano alle blue/green distribuzioni:
+ Le implementazioni blu/verde non supportano la gestione delle password degli utenti master con Gestione dei segreti AWS.
+ Se il volume di log dedicato è abilitato sul database blu, deve essere abilitato su *tutte* le istanze database, incluse le repliche di lettura.
+ 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_scheduler`parametro) 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.
+ Non è possibile modificare un'istanza decrittografato in un'istanza crittografato. Inoltre, non è possibile modificare un’istanza database crittografata in un’istanza database decrittografata.
+ Non è possibile modificare un’istanza database dell’ambiente blu con una versione successiva del motore rispetto all’istanza 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 a cascata
+ Repliche di lettura tra regioni diverse
+ CloudFormation
+ Implementazioni di cluster DB Multi-AZ
Le implementazioni blu/verde sono supportate per le implementazioni dell'istanza database Multi-AZ. Per ulteriori informazioni sulle implementazioni Multi-AZ, consulta [Configurazione e gestione di un’implementazione Multi-AZ per Amazon RDS](Concepts.MultiAZ.md).
### : limitazioni per le implementazioni blue/green
Le seguenti limitazioni si applicano alle implementazioni : blue/green
+ L’istanza database dell’ambiente blu non può essere una replica di log binari esterna.
+ Se il database di origine è associato a un gruppo di opzioni personalizzato, non è possibile specificare un aggiornamento della versione principale quando si crea la distribuzione. blue/green
In questo caso, puoi creare una blue/green distribuzione senza specificare un aggiornamento della versione principale. Quindi, puoi aggiornare il database nell'ambiente verde. Per ulteriori informazioni, consulta [Aggiornamento della versione del motore di di un'istanza database](USER_UpgradeDBInstance.Upgrading.md).
+ Le distribuzioni blu/green non supportano il driver AWS JDBC per MySQL. [Per ulteriori informazioni, consulta Limitazioni note su.](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations) GitHub
### Limitazioni di RDS per PostgreSQL per le implementazioni con replica fisica blue/green
Le seguenti limitazioni si applicano alle distribuzioni RDS per blue/green PostgreSQL che utilizzano la replica fisica. Per una spiegazione di quando le blue/green distribuzioni utilizzano la replica fisica anziché la replica logica, vedere. [Metodi di replica PostgreSQL per le distribuzioni blue/green](blue-green-deployments-replication-type.md)
+ Dopo aver creato l’ambiente verde, non è possibile eseguire un aggiornamento manuale della versione principale.
+ Le implementazioni blu/verde che utilizzano la replica fisica non supportano le modifiche dello schema nell’ambiente verde, in quanto è strettamente di sola lettura.
+ L’istanza database blu non può essere un’origine logica (publisher) o una replica (subscriber).
+ Durante la configurazione della replica ritardata in RDS per PostgreSQL, le implementazioni blu/verde hanno le seguenti limitazioni:
+ **Istanza di origine verde**: `recovery_min_apply_delay parameter` viene ignorato, anche se configurato nel gruppo di parametri. Le eventuali impostazioni di ritardo sull’istanza di origine verde non hanno effetto.
+ **Istanza di replica verde**: `recovery_min_apply_delay parameter` è completamente supportato e applicato al file di configurazione PostgreSQL. Le impostazioni di ritardo funzionano come previsto durante il flusso di lavoro di switchover.
+ La replica ritardata non è compatibile con le distribuzioni Blue/Green RDS per gli aggiornamenti delle versioni principali.
### Limitazioni di logica blue/green
Le seguenti limitazioni si applicano alle implementazioni blu/verde di RDS per PostgreSQL blue/green deployments che utilizzano la replica logica. Per una spiegazione di quando blue/green le distribuzioni utilizzano la replica logica anziché la replica fisica, consulta. [Metodi di replica PostgreSQL per le distribuzioni blue/green](blue-green-deployments-replication-type.md)
+ Le tabelle [non registrate nei log](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED) non vengono replicate nell’ambiente verde su tabelle non registrate.
+ L’istanza database blu non può essere un’origine logica (publisher) o una replica (subscriber).
+ Se l’istanza database blu è configurata come server esterno di un’estensione FDW (Foreign Data Wrapper), è necessario utilizzare il nome dell’endpoint dell’istanza 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 dell’istanza 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 dell’istanza.
+ Il [processo di applicazione](https://www.postgresql.org/docs/current/logical-replication-architecture.html) 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)](https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html).
+ Durante la configurazione della replica ritardata in RDS per PostgreSQL, le implementazioni blu/verde hanno le seguenti limitazioni:
+ **Istanza di origine verde**: `recovery_min_apply_delay parameter` viene ignorato, anche se configurato nel gruppo di parametri. Le eventuali impostazioni di ritardo sull’istanza di origine verde non hanno effetto.
+ **Istanza di replica verde**: `recovery_min_apply_delay parameter` è completamente supportato e applicato al file di configurazione PostgreSQL. Le impostazioni di ritardo funzionano come previsto durante il flusso di lavoro di switchover.
+ La replica ritardata non è compatibile con le Blue/Green distribuzioni RDS per gli aggiornamenti delle versioni principali.
+ La creazione di nuove partizioni sulle tabelle partizionate non è supportata durante le implementazioni blu/verde per RDS per PostgreSQL. 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_partman`estensione 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_cron`estensione 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.
+ 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](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md).
#### Limitazioni specifiche della replica logica per le distribuzioni blue/green
PostgreSQL presenta alcune restrizioni relative alla replica logica, che si traducono in limitazioni durante la creazione di distribuzioni per i cluster PostgreSQL DB (RDS per le istanze database PostgreSQL blue/green per PostgreSQL).
La tabella seguente descrive le limitazioni della replica logica che si applicano alle implementazioni blu/verde per RDS per PostgreSQL. Per ulteriori informazioni, consulta [Restrictions](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) 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 Amazon RDS 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 Amazon RDS PostgreSQL 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, Amazon RDS 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 Amazon RDS 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. |
| 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 lo switchover, è possibile aggiornarle manualmente utilizzando il comando [REFRESH MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html) 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](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). |
## Considerazioni per le implementazioni blue/green
Amazon RDS tiene traccia delle risorse nelle blue/green distribuzioni con l'ausilio `DbClusterResourceId` di `DbiResourceId` risorsa. Questo ID di risorsa è un identificatore Regione AWS univoco e immutabile per la risorsa.
L’ID della *risorsa* è separato dall’ID ***dell’istanza* database. Ciascuno di essi è elencato nella configurazione del database nella console RDS.
Il nome (ID di istanza) 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 istanza database potrebbe essere `mydb` nell'ambiente blu. Dopo lo switchover, la stessa istanza database potrebbe essere rinominata in `mydb-old1`. Tuttavia, l'ID risorsa dell'istanza 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 blu IDs che era 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 RDS in AWS CloudTrail](logging-using-cloudtrail.md).
+ 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 RDS](USER_PerfInsights.md).
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 RDS](UsingWithRDS.IAM.md).
+ Se sono disponibili ruoli IAM associati all’istanza database, è necessario riassociarli dopo lo switchover. I ruoli collegati non vengono copiati automaticamente nell’ambiente verde.
+ Se si esegue l'autenticazione nell'istanza database utilizzando [l'autenticazione del database IAM](UsingWithRDS.IAMDBAuth.md), 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](UsingWithRDS.IAMDBAuth.IAMPolicy.md).
+ Se utilizzi AWS Backup per gestire i backup automatici delle risorse in una distribuzione blu/verde, modifica la risorsa IDs utilizzata entro dopo lo switchover. AWS Backup Per ulteriori informazioni, consulta [Utilizzo di AWS Backup per gestire backup automatizzati per Amazon RDS](AutomatedBackups.AWSBackup.md).
+ Se desideri ripristinare uno snapshot DB manuale o automatizzato per un'istanza DB che faceva parte di una blue/green distribuzione, assicurati di ripristinare lo snapshot DB corretto esaminando l'ora in cui è stata scattata l'istantanea. Per ulteriori informazioni, consulta [Ripristino in un’istanza database](USER_RestoreFromSnapshot.md).
+ Se desideri descrivere un backup automatico di un'istanza database dell'ambiente blu precedente o ripristinarlo a un determinato momento, utilizza l'ID risorsa per l'operazione.
Poiché il nome dell'istanza database viene modificato durante lo switchover, non è possibile utilizzare il nome precedente per le operazioni `DescribeDBInstanceAutomatedBackups` o `RestoreDBInstanceToPointInTime`.
Per ulteriori informazioni, consulta [Ripristino di un’istanza database a un punto temporale specifico per Amazon RDS](USER_PIT.md).
+ Quando si aggiunge una replica di lettura a un'istanza database nell'ambiente verde di un'implementazione blu/verde, la nuova replica di lettura non sostituisce una replica di lettura dell'ambiente blu al momento dello switchover. Tuttavia, la nuova replica di lettura viene mantenuta nel nuovo ambiente di produzione dopo lo switchover.
+ 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.
+ Quando si elimina un'istanza DB nell'ambiente verde di una blue/green distribuzione, non è possibile creare una nuova istanza DB per sostituirla nella distribuzione. blue/green
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 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.
Lo stesso comportamento si applica alle istanze database e alle repliche di lettura.
+ 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 gli 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 [Etichettatura delle Amazon RDS](USER_Tagging.md).
# Best practice per le implementazioni di Amazon RDS blue/green
Di seguito sono riportate le best practice per le distribuzioni. blue/green
**Topics**
+ [Procedure consigliate generali per le implementazioni blue/green](#blue-green-deployments-best-practices-general)
+ [RDS per MySQL : best practice MySQL per le implementazioni blue/green](#blue-green-deployments-best-practices-mysql)
+ [RDS per MySQL Global Database: best practice per le implementazioni blue/green](#blue-green-deployments-best-practices-agd)
+ [Metodi di replica PostgreSQL per le distribuzioni blue/green](blue-green-deployments-replication-type.md)
## Procedure consigliate generali per le implementazioni blue/green
Le seguenti best practice generali si utilizzano quando si crea un’implementazione blu/verde.
+ Esegui accuratamente il test delle istanze database nell'ambiente verde prima di effettuare lo switchover.
+ Mantieni i tuoi database nell'ambiente verde di sola lettura. Si consiglia di abilitare le operazioni di scrittura nell'ambiente verde con cautela perché possono causare conflitti di replica nell'ambiente verde. Possono inoltre generare dati non previsti nei database di produzione dopo lo switchover.
+ Se utilizzi una blue/green distribuzione per implementare modifiche allo schema, apporta solo modifiche compatibili con la replica.
Ad esempio, è possibile aggiungere nuove colonne alla fine di una tabella senza interrompere la replica dall’implementazione blu all’implementazione verde. Tuttavia, le modifiche dello schema, come la ridenominazione delle colonne o delle tabelle, interrompono la replica nell'implementazione verde.
Per ulteriori informazioni sulle modifiche compatibili con la replica, consulta [Replication with Differing Table Definitions on Source and Replica](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) nella documentazione MySQL e [Restrictions](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) nella documentazione della replica logica PostgreSQL.
**Nota**
Questa limitazione non si applica alle implementazioni RDS per blue/green PostgreSQL che utilizzano la replica fisica. Per ulteriori informazioni, consulta [Limitazioni di RDS per PostgreSQL per le implementazioni con replica fisica blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-physical).
+ Dopo aver creato la blue/green distribuzione, gestisci il lazy loading, se necessario. Assicurati che il caricamento dei dati sia completato prima di effettuare lo switchover. Per ulteriori informazioni, consulta [Lazy loading e inizializzazione dello storage per le implementazioni blue/green](blue-green-deployments-creating.md#blue-green-deployments-creating-lazy-loading).
+ Quando passi da una blue/green distribuzione all'altra, segui le best practice di commutazione. Per ulteriori informazioni, consulta [Best practice per lo switchover](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices).
## RDS per MySQL : best practice MySQL per le implementazioni blue/green
Prendi in considerazione le seguenti best practice quando crei una blue/green distribuzione da un cluster RDS for MySQL DB MySQL DB.
+ Evita di utilizzare motori di archiviazione non transazionali, come MyISAM, che non sono ottimizzati per la replica.
+ Ottimizza le repliche di lettura e l’ambiente verde per la replica di log binari. Se supportata dal tuo motore DB, abilita la replica GTID, parallela e antiurto per garantire la coerenza e la durabilità dei dati prima di creare la distribuzione. blue/green Per ulteriori informazioni, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md).
+ Se l’ambiente verde presenta un ritardo di replica, considera i seguenti requisiti:
+ Imposta temporaneamente il parametro `innodb_flush_log_at_trx_commit` su `2` nel gruppo di parametri di database verde. Una volta recuperata la replica, ripristina il valore predefinito di `1` prima dello switchover. Se si verifica un arresto imprevisto o anomalo con il valore temporaneo del parametro, ricrea l’ambiente verde per evitare il danneggiamento dei dati non rilevati.
+ Per ridurre la latenza di scrittura e migliorare il throughput della replica, modifica temporaneamente le istanze database Multi-AZ verdi in istanze database Single-AZ. Riabilita le istanze Multi-AZ subito prima dello switchover.
## RDS per MySQL Global Database: best practice per le implementazioni blue/green
Oltre alle best practice generali e specifiche del motore sopra elencate, prendi in considerazione le seguenti best practice per l' RDS for MySQL DB Aurora Global Database.
+ Monitora le seguenti CloudWatch metriche per identificare i periodi di scarsa attività nell'ambiente di produzione:
+ `DatabaseConnections`
+ `ActiveTransactions`
Pianifica il blue/green passaggio al digitale durante la finestra di manutenzione pianificata o durante un periodo di bassa attività.
+ Blue/Green switchover duration varies based on your workload and the number of secondary regions. When you initiate a blue/greenswitchover, il servizio attende che il ritardo della replica raggiunga lo zero prima di procedere. Si consiglia di verificare il ritardo della replica prima di iniziare uno switchover.
+ Se intendi utilizzare un parametro DB o un gruppo di parametri DB Cluster diverso da quello predefinito per il tuo ambiente verde, crea il gruppo di parametri desiderato con lo stesso nome in tutte le regioni secondarie prima di iniziare la distribuzione. blue/green
### Best practice di RDS per PostgreSQL per le distribuzioni blue/green
Prendi in considerazione le seguenti best practice quando crei una blue/green distribuzione da un'istanza DB RDS per PostgreSQL.
**Topics**
+ [Best practice generali per le distribuzioni di RDS per PostgreSQL blue/green](#blue-green-deployments-best-practices-postgres-general)
+ [Best practice RDS per PostgreSQL per implementazioni con replica fisica blue/green](#blue-green-deployments-best-practices-postgres-physical)
+ [Best practice RDS per PostgreSQL per implementazioni con replica logica blue/green](#blue-green-deployments-best-practices-postgres-logical)
#### Best practice generali per le distribuzioni di RDS per PostgreSQL blue/green
Prendi in considerazione le seguenti best practice generali quando crei una blue/green distribuzione da un'istanza DB RDS per PostgreSQL.
+ Aggiorna tutte le estensioni PostgreSQL alla versione più recente prima di creare una distribuzione. blue/green Per ulteriori informazioni, consulta [Aggiornamento delle estensioni PostgreSQL nei database RDS per PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md).
+ Le transazioni di lunga durata possono causare un notevole ritardo di replica. Per ridurre il ritardo di replica, valuta le seguenti operazioni:
+ Riduci le transazioni di lunga durata che possono essere ritardate fino a quando l’ambiente verde non raggiunge il livello dell’ambiente blu.
+ Riduci le operazioni di massa sull’ambiente blu fino a quando l’ambiente verde non raggiungerà il livello dell’ambiente blu.
+ Avvia un'operazione manuale di congelamento sottovuoto su tabelle occupate prima di creare la distribuzione. blue/green
+ Per PostgreSQL 12 e versioni successive, disabilita il parametro `index_cleanup` sulle tabelle di grandi dimensioni o particolarmente utilizzate per aumentare la frequenza della manutenzione regolare dei database blu. Per ulteriori informazioni, consulta [Vacuum di una tabella il più rapidamente possibile](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
**Nota**
Saltare regolarmente la pulizia dell’indice durante il vacuum può causare un aumento dell’indice, che potrebbe compromettere le prestazioni di scansione. Come best practice, utilizzate questo approccio solo durante l'utilizzo di una blue/green distribuzione. Una volta completata l’implementazione, è consigliabile riprendere la manutenzione e la pulizia regolari dell’indice.
+ Una replica lenta può causare il riavvio frequente di mittenti e destinatari, il che ritarda la sincronizzazione. Per assicurare che rimangano attivi, disabilita i timeout impostando il parametro `wal_sender_timeout` su `0` nell’ambiente blu e il parametro `wal_receiver_timeout` su `0` nell’ambiente verde.
+ Per evitare che i segmenti WAL (write-ahead log) vengano rimossi dall’ambiente blu, imposta il parametro `wal_keep_segments` su 15625 per PostgreSQL 13 e versioni precedenti. Per la versione 14 e successive, imposta il parametro `wal_keep_size` su 1 TiB, se c’è abbastanza spazio di archiviazione libero.
#### Best practice RDS per PostgreSQL per implementazioni con replica fisica blue/green
Con la replica fisica, Amazon RDS crea una replica di lettura dell’istanza database di origine. Per i parametri correlati, il monitoraggio, l’ottimizzazione e la risoluzione dei problemi, consulta [Utilizzo delle repliche di lettura per Amazon RDS per PostgreSQL](USER_PostgreSQL.Replication.ReadReplicas.md).
Per una spiegazione di quando le blue/green distribuzioni utilizzano la replica fisica anziché la replica logica, vedere. [Metodi di replica PostgreSQL per le distribuzioni blue/green](blue-green-deployments-replication-type.md)
#### Best practice RDS per PostgreSQL per implementazioni con replica logica blue/green
Prendi in considerazione le seguenti best practice quando crei una distribuzione che utilizza la replica logica. blue/green Per una spiegazione di quando le blue/green distribuzioni utilizzano la replica logica anziché la replica fisica, consulta. [Metodi di replica PostgreSQL per le distribuzioni blue/green](blue-green-deployments-replication-type.md)
+ Se il database dispone di memoria libera sufficiente, aumenta il valore del parametro di database `logical_decoding_work_mem` nell’ambiente blu. In questo modo si riduce la decodifica su disco e si utilizza invece la memoria. Per ulteriori informazioni, consultare la [documentazione di PostgreSQL](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM).
+ È possibile monitorare l'overflow delle transazioni che vengono scritte su disco utilizzando la metrica. `ReplicationSlotDiskUsage` CloudWatch Questa metrica offre approfondimenti sull’utilizzo del disco degli slot di replica, che consentono di individuare quando i dati delle transazioni superano la capacità di memoria e vengono archiviati su disco. È possibile monitorare la memoria liberabile con la metrica. `FreeableMemory` CloudWatch Per ulteriori informazioni, consulta [Parametri a CloudWatch livello di istanza Amazon per Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
+ In RDS per PostgreSQL 14 e versioni successive, è possibile monitorare la dimensione dei file di overflow logico utilizzando la visualizzazione di sistema `[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)`.
+ Se utilizzi l’estensione `aws_s3`, assicurati di fornire all’istanza database verde l’accesso ad Amazon S3 tramite un ruolo IAM dopo la creazione dell’ambiente verde. In tal modo i comandi di importazione ed esportazione continuano a funzionare dopo lo switchover. Per istruzioni, consulta [Configurazione dell'accesso a un bucket Amazon S3](postgresql-s3-export-access-bucket.md).
+ Esamina le prestazioni delle istruzioni UPDATE e DELETE e valuta se la creazione di un indice sulla colonna utilizzata nella clausola WHERE può ottimizzare queste query. Può migliorare le prestazioni quando le operazioni vengono ripetute nell’ambiente verde.
+ Se utilizzi i trigger, assicurati che non interferiscano con la creazione, l’aggiornamento e l’eliminazione di oggetti `pg_catalog.pg_publication`, `pg_catalog.pg_subscription` e `pg_catalog.pg_replication_slots` i cui nomi iniziano con “rds”.
+ Se specifichi una versione del motore superiore per l’ambiente verde, esegui l’operazione `ANALYZE` su tutti i database per aggiornare la tabella `pg_statistic`. Le statistiche di ottimizzazione non vengono trasferite durante un aggiornamento della versione principale, quindi è necessario rigenerare tutte le statistiche per evitare problemi di prestazioni. Per ulteriori best practice per gli aggiornamenti della versione principale, consulta [Come eseguire l’aggiornamento a una versione principale per RDS per PostgreSQL](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md).
+ Evita di configurare i trigger come `ENABLE REPLICA` o `ENABLE ALWAYS` se il trigger viene utilizzato sull’origine per manipolare i dati. In caso contrario, il sistema di replica propaga le modifiche ed esegue il trigger, che porta a una duplicazione.
# Metodi di replica PostgreSQL per le distribuzioni blue/green
Amazon RDS for PostgreSQL utilizza principalmente la replica fisica per le distribuzioni. blue/green Tuttavia, se richiedi un aggiornamento della versione principale quando crei la blue/green distribuzione e l'istanza DB di origine esegue una delle versioni di PostgreSQL elencate nella tabella seguente, Amazon RDS utilizza invece la replica logica.
La tabella seguente descrive quando Amazon RDS utilizza la replica fisica rispetto a quella logica per le distribuzioni PostgreSQL. blue/green
| Versione dell’istanza database PostgreSQL di origine | Azione di aggiornamento durante la distribuzione blue/green | Metodo di replica |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/blue-green-deployments-replication-type.html) | Aggiornamento della versione principale(versione principale del motore dell’istanza verde successiva a quella blu) | Replica logica |
| Tutte le versioni supportate | Aggiornamento della versione secondaria o nessun aggiornamento(versione principale del motore dell’istanza verde uguale a quella blu) | Replica fisica. |
**Nota**
Gli aggiornamenti delle versioni principali non sono supportati per le blue/green distribuzioni con RDS di origine per PostgreSQL versioni 15.3 e precedenti, 14.8 e precedenti, 13.11 e precedenti, 12.15 e precedenti o 11.20 e precedenti.
Per informazioni sui limiti delle blue/green distribuzioni che utilizzano la replica fisica e logica, consulta le seguenti sezioni:
+ [Limitazioni di RDS per PostgreSQL per le implementazioni con replica fisica blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-physical)
+ [Limitazioni di logica blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-logical)
# Creazione di una blue/green distribuzione in Amazon RDS
Quando crei una blue/green distribuzione, specifichi l'istanza DB di origine da copiare nella distribuzione. L'istanza scelta è l'istanza database di produzione e diventa l'istanza database primaria nell'ambiente blu. Questa istanza database viene copiata nell'ambiente verde e RDS configura la replica dall'istanza database dell'ambiente blu all'istanza database dell'ambiente verde.
RDS copia la topologia e le funzionalità dell’ambiente blu in un’area di staging. Quando l’istanza database blu ha delle repliche di lettura, queste vengono copiate come repliche dell’istanza verde. Lo spazio di archiviazione allocato di tutte le repliche verdi corrisponde all’istanza primaria verde, mentre gli altri parametri di archiviazione vengono ereditati dalle repliche blu.
Se l'istanza database blu è un'implementazione di istanza database multi-AZ, l'istanza database verde viene creata come un'implementazione di istanza database multi-AZ.
**Topics**
+ [Preparazione per una blue/green distribuzione](#blue-green-deployments-creating-preparing)
+ [Specificazione delle modifiche durante la creazione di una distribuzione blue/green](#blue-green-deployments-creating-changes)
+ [Lazy loading e inizializzazione dello storage per le implementazioni blue/green](#blue-green-deployments-creating-lazy-loading)
+ [Creare una distribuzione blue/green](#blue-green-deployments-creating-create)
+ [Impostazioni per la creazione di distribuzioni blue/green](#create-blue-green-settings)
## Preparazione per una blue/green distribuzione
Esistono alcuni passaggi da eseguire prima di creare una blue/green distribuzione, a seconda del motore su cui è in esecuzione l'istanza database del .
**Topics**
+ [Preparazione di un'istanza DB RDS per MySQL o RDS for MariaDB per una distribuzione blue/green](#blue-green-deployments-creating-preparing-mysql)
+ [Preparazione di un'istanza DB RDS per PostgreSQL per una distribuzione con replica fisica blue/green](#blue-green-deployments-creating-preparing-postgres-physical)
+ [Preparazione di un'istanza DB RDS per PostgreSQL per una distribuzione con replica logica blue/green](#blue-green-deployments-creating-preparing-postgres-logical)
### Preparazione di un'istanza DB RDS per MySQL o RDS for MariaDB per una distribuzione blue/green
Prima di creare una blue/green distribuzione per un'istanza DB RDS for MySQL o RDS for MariaDB, devi abilitare i backup automatici. Per istruzioni, consulta [Abilitazione dei backup automatici](USER_WorkingWithAutomatedBackups.Enabling.md).
### Preparazione di un'istanza DB RDS per PostgreSQL per una distribuzione con replica fisica blue/green
Prima di creare una distribuzione RDS per blue/green PostgreSQL che utilizza la replica fisica, assicurati di fare quanto segue. Per l’elenco delle versioni che utilizzano la replica fisica rispetto alla replica logica, consulta [Metodi di replica PostgreSQL per le distribuzioni blue/green](blue-green-deployments-replication-type.md).
+ Abilita i backup automatici sull’istanza database. Per istruzioni, consulta [Abilitazione dei backup automatici](USER_WorkingWithAutomatedBackups.Enabling.md).
+ Verifica che l'istanza database non sia l'origine o la destinazione della replica esterna. Per ulteriori informazioni, consulta [Limitazioni generali per le distribuzioni blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-general).
### Preparazione di un'istanza DB RDS per PostgreSQL per una distribuzione con replica logica blue/green
Prima di creare una distribuzione RDS per blue/green PostgreSQL che utilizza la replica logica, assicurati di fare quanto segue. Per l’elenco delle versioni che utilizzano la replica logica rispetto alla replica fisica, consulta [Metodi di replica PostgreSQL per le distribuzioni blue/green](blue-green-deployments-replication-type.md).
+ Associa l'istanza a un gruppo di parametri di database personalizzato con la replica logica (`rds.logical_replication`) attivata. La replica logica è necessaria per la replica dall'ambiente blu nell'ambiente verde. Per istruzioni, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
Poiché blue/green le distribuzioni richiedono almeno un lavoratore in background per database, assicurati di ottimizzare le seguenti impostazioni di configurazione in base al tuo carico di lavoro. Per istruzioni su come ottimizzare ogni impostazione, consulta [Impostazioni di configurazione](https://www.postgresql.org/docs/current/logical-replication-config.html) nella documentazione PostgreSQL.
+ `max_replication_slots`
+ `max_wal_senders`
+ `max_logical_replication_workers`
+ `max_worker_processes`
Dopo aver abilitato la replica logica e impostato tutte le opzioni di configurazione, assicurati di riavviare l'istanza DB in modo che le modifiche abbiano effetto. Blue/green le distribuzioni *richiedono* che l'istanza DB sia sincronizzata con il gruppo di parametri DB, altrimenti la creazione fallisce. Per ulteriori informazioni, consulta [Riavvio di un'istanza DB DB](USER_RebootInstance.md).
+ Verifica che l'istanza database non sia l'origine o la destinazione della replica esterna. Per ulteriori informazioni, consulta [Limitazioni generali per le distribuzioni blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-general).
+ Assicurati che tutte le tabelle dell'istanza database abbiano una chiave primaria. La replica logica di PostgreSQL non consente operazioni `UPDATE` o `DELETE` su tabelle che non dispongono di una chiave primaria.
+ RDS per PostgreSQL utilizza la replica logica nativa di PostgreSQL, memorizzando i segmenti WAL (write-ahead log) sull’istanza blu fino a quando non vengono riprodotti nell’ambiente verde. Prima di creare una blue/green distribuzione, verifica che l'istanza blu abbia una capacità adeguata controllando le seguenti metriche:
+ `FreeStorageSpace`
+ `TransactionLogsGeneration`
+ `TransactionLogsDiskUsage`
+ `OldestReplicationSlotLag`
Per stimare lo spazio di archiviazione aggiuntivo richiesto sull'istanza blu, monitora la `TransactionLogsGeneration` CloudWatch metrica durante i periodi di picco di carico di lavoro. Ad esempio, se il carico di lavoro genera 100 GB di dati WAL nell’arco di 24 ore, è necessario avere almeno 100 GB di spazio di archiviazione aggiuntivo per ospitare i segmenti WAL di un giorno. Per ulteriori informazioni, consulta [Monitoraggio di parametri in un'istanza Amazon RDS](CHAP_Monitoring.md).
## Specificazione delle modifiche durante la creazione di una distribuzione blue/green
È possibile apportare le seguenti modifiche al di istanze DB nell'ambiente verde quando si crea la blue/green distribuzione.
È possibile apportare altre modifiche all'istanza database nell'ambiente verde dopo l'implementazione. Ad esempio, è possibile specificare una versione del motore superiore o un gruppo di parametri diverso.
Per ulteriori informazioni sulla modifica di un’istanza di database, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md).
**Topics**
+ [Specifica di una versione successiva del motore](#blue-green-deployments-engine-version)
+ [Specifica di un gruppo di parametri di database](#blue-green-deployments-parameters)
+ [Modifica delle impostazioni di archiviazione e prestazioni](#blue-green-deployments-resize)
+ [Abilitazione di Scritture ottimizzate per RDS](#blue-green-deployments-db-instance)
+ [Aggiornamento della configurazione di archiviazione](#blue-green-deployments-storage)
### Specifica di una versione successiva del motore
È possibile specificare una versione superiore del motore se si desidera testare un aggiornamento del motore di database. Al momento dello switchover, il database viene aggiornato alla versione principale o secondaria specificata del motore di database.
### Specifica di un gruppo di parametri di database
È possibile verificare in che modo le modifiche ai parametri influiscono sulle istanze database nell'ambiente verde o specificare un gruppo di parametri per una nuova versione principale del motore di database in caso di aggiornamento.
Se si specifica un gruppo di parametri database diverso, il gruppo specificato viene associato a tutte le istanze database nell'ambiente verde. Se non si specifica un gruppo di parametri diverso, ogni istanza database nell'ambiente verde viene associata al gruppo di parametri della corrispondente istanza database blu.
### Modifica delle impostazioni di archiviazione e prestazioni
Modifica delle impostazioni di archiviazione e prestazioni nell’ambiente verde per ottimizzare l’allocazione delle risorse. Queste impostazioni includono lo spazio di archiviazione allocato, la capacità di IOPS allocata, il tipo di archiviazione e il throughput di archiviazione (per l’archiviazione gp3).
È possibile modificare il tipo di archiviazione dell’istanza database verde in gp2, gp3, io1 o io2. Per l’archiviazione gp3, è anche possibile regolare il throughput di archiviazione per migliorare le prestazioni di trasferimento dei dati per carichi di lavoro con volumi elevati o per ridurre i costi per le applicazioni a uso meno intensivo. Per ulteriori informazioni, consulta [Storage delle istanze di database Amazon RDS](CHAP_Storage.md).
È anche possibile scegliere di aumentare o diminuire lo spazio di archiviazione allocato nell’ambiente verde. Tuttavia, una riduzione dello spazio di archiviazione si verifica solo se l’archiviazione di destinazione allocata è almeno il 20% in più rispetto all’utilizzo corrente dello spazio di archiviazione. Se riduce lo spazio di archiviazione allocato, Amazon RDS avvia un aggiornamento della configurazione dell’archiviazione. Per ulteriori informazioni, consulta [Aggiornamento della configurazione di archiviazione](#blue-green-deployments-storage). Lo storage di destinazione minimo viene calcolato come:
```
Minimum Target Storage = Total Allocated Storage × Current Apparent Utilization × 1.2
```
1. Storage allocato totale: la capacità di storage fornita per l'istanza DB, visibile nella console RDS.
1. Utilizzo apparente attuale: la percentuale di storage allocato in uso. Per stimarlo, utilizza la `os.fileSys.usedPercent` metrica di Performance Insights (Database Insights) o Enhanced Monitoring.
**Nota**
Poiché l'utilizzo dello storage varia nel tempo, consigliamo di impostare lo storage di destinazione leggermente al di sopra del minimo calcolato per tenere conto dei potenziali aumenti durante il processo di riduzione.
Se l’istanza database blu utilizza l’archiviazione magnetica, è necessario cambiare l’istanza database verde in un tipo di archiviazione General Purpose o Capacità di IOPS allocata per aumentare o diminuire lo spazio di archiviazione allocato.
### Abilitazione di Scritture ottimizzate per RDS
È possibile utilizzare una blue/green distribuzione per eseguire l'aggiornamento a una classe di istanze DB che supporti RDS Optimized Writes. È possibile abilitare Scritture ottimizzate per RDS solo su un database *creato* con una classe di istanza database supportata. Pertanto, questa opzione crea un database verde con una classe di istanza database supportata che consente di attivare Scritture ottimizzate per RDS sull'istanza database verde.
Se si esegue l'aggiornamento da una classe di istanza database che non supporta Scritture ottimizzate per RDS a una che lo supporta, è necessario anche aggiornare la configurazione di archiviazione dell'istanza database verde. Per ulteriori informazioni, consulta [Aggiornamento della configurazione di archiviazione](#blue-green-deployments-storage).
È possibile aggiornare solo la classe dell'istanza database verde *primaria*. Per impostazione predefinita, le repliche di lettura nell'ambiente verde ereditano le impostazioni dell'istanza database dall'ambiente blu. Dopo aver creato l'ambiente verde, è necessario modificare manualmente la classe di istanza database delle repliche di lettura nell'ambiente verde.
A seconda della versione del motore e della classe dell'istanza database blu, alcuni aggiornamenti della classe di istanza non sono supportati. Per maggiori informazioni sulle classi di istanza database, consulta [Classi di istanze DB ](Concepts.DBInstanceClass.md).
### Aggiornamento della configurazione di archiviazione
Se il database blu non utilizza la configurazione di archiviazione più recente, RDS può migrare l'istanza database verde dalla configurazione di archiviazione precedente (file system a 32 bit) alla configurazione preferita. È possibile utilizzare RDS Blue/Green Deployments per superare i limiti di scalabilità relativi allo storage e alle dimensioni dei file per i vecchi file system a 32 bit. Inoltre, questa impostazione modifica la configurazione di archiviazione per renderla compatibile con Scritture ottimizzate per RDS se la classe di istanza database specificata supporta questa funzionalità.
**Nota**
L'aggiornamento della configurazione di archiviazione rappresenta un saldo di I/O-intensive operation and leads to longer creation times for blue/green deployments. The storage upgrade process is faster if the blue DB instance uses Provisioned IOPS SSD (io1 or io2 Block Express) storage, and if you provisoned the green environment with an instance size of 4xlarge or larger. Storage upgrades involving General Purpose SSD (gp2) storage can deplete your I/O credito, che comporta tempi di aggiornamento più lunghi. Per ulteriori informazioni, consulta [Storage delle istanze di database Amazon RDS](CHAP_Storage.md).
Durante l’aggiornamento dell’archiviazione, l’istanza database verde è temporaneamente non disponibile, mentre l’istanza database blu rimane disponibile. La replica viene sospesa durante questo periodo. Monitora lo spazio di archiviazione sull’istanza blu e valuta la possibilità di eseguire un dimensionamento se l’archiviazione raggiunge il 90%, poiché l’istanza verde scala automaticamente del 10% dopo l’aggiornamento.
Questa opzione è disponibile solo se il database blu *non* utilizza la configurazione di archiviazione più recente o se stai modificando la classe dell'istanza database nell'ambito della stessa richiesta. È possibile aggiornare la configurazione dell’archiviazione solo quando si crea inizialmente un’implementazione blu/verde.
## Lazy loading e inizializzazione dello storage per le implementazioni blue/green
Quando crei una blue/green distribuzione, Amazon RDS crea l'istanza DB principale nell'ambiente verde eseguendo il ripristino da uno snapshot DB. Dopo la creazione, l’istanza database verde e le relative repliche di lettura continuano a caricare i dati in background tramite un processo noto come *caricamento lento*.
Il caricamento lento carica i blocchi di dati solo quando le applicazioni li richiedono. Se si tenta di accedere a dati che non sono ancora stati caricati, Amazon EBS li recupera immediatamente da Amazon S3, mentre i restanti dati continuano a essere caricati in background. Per ulteriori informazioni, consulta [Snapshot Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html).
Per accelerare le prestazioni dell’intero volume, Amazon RDS fornisce l’inizializzazione dell’archiviazione, che legge tutti i blocchi nel volume dell’ambiente verde. Amazon EBS scarica in modo proattivo i blocchi da Amazon S3, offrendo le massime prestazioni di volume sin dal primo utilizzo. L’inizializzazione dell’archiviazione avviene interamente in background, garantendo che non abbia alcun impatto sulla disponibilità dell’istanza database o sulle attività in corso, come l’applicazione di patch o gli aggiornamenti.
L'inizializzazione dello storage è disponibile solo per le istanze in blue/green distribuzioni con `gp2` tipi di volume,, e. `gp3` `io1` `io2` Supporta tutte le classi di istanza ad eccezione delle famiglie t3 e t4. Se si modifica un’istanza database verde di un’implementazione Single-AZ in un’implementazione di istanza database Multi-AZ, l’inizializzazione dell’archiviazione include il nodo secondario nella configurazione Multi-AZ.
Durante l’inizializzazione dell’archiviazione, l’istanza rimane completamente disponibile e utilizzabile per le operazioni del database, anche se l’archiviazione potrebbe non raggiungere le prestazioni ottimali fino al completamento dell’inizializzazione. Durante l’inizializzazione dell’archiviazione, lo stato generale dell’istanza cambia in **Storage-initialization** e l’indicatore di avanzamento riflette il livello minimo di inizializzazione su tutti i volumi dell’istanza database.
Usa la console o l' AWS CLI API Amazon RDS per monitorare l'inizializzazione dello storage.
------
#### [ Console ]
In Console di gestione AWS, puoi vedere l'avanzamento dell'inizializzazione dello storage con lo stato dell'istanza DB.
![\[Indicatore di avanzamento dell'inizializzazione dello storage per una distribuzione blue/green\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/storage-initialization-bg.png)
------
#### [ AWS CLI ]
Con AWS CLI, è possibile monitorare l'inizializzazione dello storage con il [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)comando. Il campo `PercentProgress` nella risposta mostra la percentuale di dati recuperati da Amazon S3.
```
aws rds describe-db-instances --db-instance-identifier my-db-instance
{
"DBInstances": [
{
"DBInstanceIdentifier": "my-db-instance",
"DBInstanceClass": "db.m5.2xlarge",
"Engine": "postgres",
"DBInstanceStatus": "storage-initialization",
...
"PercentProgress": "34"
}
]
}
```
------
#### [ Amazon RDS API ]
[Con l'API Amazon RDS, puoi recuperare lo stato dell'inizializzazione dello storage chiamando l'azione Descrivi. DBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html)
------
L’indicatore di avanzamento si aggiorna man mano che il processo di inizializzazione in background avanza, consentendo di monitorare lo stato di preparazione dell’archiviazione prima del completamento del processo di inizializzazione. L’inizializzazione dell’archiviazione consente di ottimizzare le prestazioni man mano che l’istanza database verde diventa completamente operativa.
## Creare una distribuzione blue/green
È possibile creare una blue/green distribuzione utilizzando Console di gestione AWS l' AWS CLI API RDS o la.
### Console
**Per creare una distribuzione blue/green**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione, scegli **Databases** (Database) quindi seleziona l'istanza da copiare nell'ambiente verde.
1. Scegli **Operazioni**, **Crea implementazione blu/verde**.
Viene visualizzata la pagina **Crea blue/green distribuzione**.
![\[Crea blue/green distribuzione\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment-create.png)
1. Esamina gli identificatori del database blu. Assicurati che corrispondano alle istanze database che ti aspetti nell’ambiente blu. In caso contrario, scegli **Cancel** (Annulla).
1. Per il **nome della distribuzione blu/verde**, inserisci un nome per la blue/green distribuzione.
1. Nelle restanti sezioni, specifica le impostazioni per l’ambiente verde. Per informazioni su ciascuna impostazione, consulta [Impostazioni per la creazione di distribuzioni blue/green](#create-blue-green-settings).
È possibile apportare altre modifiche ai database nell'ambiente verde dopo che è stato implementato.
1. Scegli **Create** (Crea).
### AWS CLI
Per creare una blue/green distribuzione utilizzando AWS CLI, usa il [create-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/create-blue-green-deployment.html)comando. Per informazioni su tutte le opzioni disponibili, consulta [Impostazioni per la creazione di distribuzioni blue/green](#create-blue-green-settings).
**Example**
Per Linux, macOS o Unix:
```
aws rds create-blue-green-deployment \
--blue-green-deployment-name my-blue-green-deployment \
--source arn:aws:rds:us-east-2:123456789012:db:mydb1 \
--target-engine-version 8.0.31 \
--target-db-parameter-group-name mydbparametergroup
```
Per Windows:
```
aws rds create-blue-green-deployment ^
--blue-green-deployment-name my-blue-green-deployment ^
--source arn:aws:rds:us-east-2:123456789012:db:mydb1 ^
--target-engine-version 8.0.31 ^
--target-db-parameter-group-name mydbparametergroup
```
### API RDS
Per creare una blue/green distribuzione utilizzando l'API Amazon RDS, utilizza l'[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html)operazione. Per ulteriori informazioni su ciascuna opzione, consulta [Impostazioni per la creazione di distribuzioni blue/green](#create-blue-green-settings).
## Impostazioni per la creazione di distribuzioni blue/green
La tabella seguente spiega le impostazioni che è possibile scegliere quando si crea una blue/green distribuzione. Per ulteriori informazioni sulle AWS CLI opzioni, vedere [create-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/create-blue-green-deployment.html). Per ulteriori informazioni sui parametri dell'API RDS, vedere [CreateBlueGreenDeployment](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html).
| Impostazione della console | Descrizione impostazione | Opzione CLI e parametro API di RDS |
| --- | --- | --- |
| **Allocated storage (Storage allocato)** | La quantità di archiviazione, in gibibyte, da allocare per l’istanza database verde. È possibile scegliere di aumentare o ridurre lo spazio di archiviazione allocato. Se l’istanza database blu utilizza l’archiviazione magnetica (`standard`), è necessario cambiare l’istanza database verde in un tipo di archiviazione General Purpose o Capacità di IOPS allocata per modificare lo spazio di archiviazione allocato nell’ambiente verde. Per ulteriori informazioni, consulta [Storage delle istanze di database Amazon RDS](CHAP_Storage.md). | **Opzione CLI:** `--target-allocated-storage` **Parametro API:** `TargetAllocatedStorage` |
| **Identificatore di implementazione blu/verde** | Un nome per la blue/green distribuzione. | **Opzione CLI:** `--blue-green-deployment-name` **Parametro API:** `BlueGreenDeploymentName` |
| Identificatore di database blu | L’identificatore dell’istanza da copiare nell’ambiente verde. Quando si utilizza la CLI o l’API, si specifica il nome della risorsa Amazon (ARN) dell’istanza. | **Opzione CLI:** `--source` **Parametro API:** `Source` |
| Gruppo di parametri del di database per i database verdi | Un gruppo di parametri da associare ai database dell’ambiente verde. | **Opzione CLI:** `--target-db-parameter-group-name` `--target-db-cluster-parameter-group-name` **Parametro API:** `TargetDBParameterGroupName` `TargetDBClusterParameterGroupName` |
| Abilita Scritture ottimizzate sul database verde | Abilita Scritture ottimizzate per RDS sull’istanza database verde primaria. Per ulteriori informazioni, consulta [Abilitazione di Scritture ottimizzate per RDS](#blue-green-deployments-db-instance). Se stai passando da una classe di istanza database che non supporta Scritture ottimizzate a una che lo supporta, devi anche eseguire un aggiornamento della configurazione dell'archiviazione. Per ulteriori informazioni, consulta [Aggiornamento della configurazione di archiviazione](#blue-green-deployments-storage). | Per la CLI e l’API, la specifica di una classe di istanza database di destinazione che supporti Scritture ottimizzate per RDS la abilita automaticamente sull’istanza database primaria verde. |
| **Versione del motore per database verdi** | Aggiorna i database nell’ambiente verde alla versione del motore di database specificata. Se non specificato, ogni database nell’ambiente verde viene creato con la stessa versione del motore dell’istanza database corrisponde nell’ambiente blu. Se scegli un’istanza database RDS per PostgreSQL, esamina e verifica i limiti della replica logica. Per ulteriori informazioni, consulta [Limitazioni specifiche della replica logica per le distribuzioni blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres). | **Opzione CLI:** `--target-engine-version` **Parametro API RDS:** `TargetEngineVersion` |
| Classe di istanza database verde | La capacità di calcolo e di memoria di ogni istanza database nell’ambiente verde, ad esempio `db.m5d.xlarge`. Questa opzione è visibile solo quando Scritture ottimizzate per RDS è abilitato per il database verde. | **Opzione CLI:** `--target-db-instance-class` **Parametro API RDS:** `TargetDBInstanceClass` |
| IOPS con provisioning | La quantità di input/output operazioni assegnate al secondo (IOPS) da allocare inizialmente per il database verde. Questo valore si applica solo all’istanza database primaria verde, non alle repliche verdi. | **Opzione CLI:** `--target-iops` **Parametro API RDS:** `TargetIops` |
| Aggiornamento della configurazione dell’archiviazione | Scegli se aggiornare la configurazione del file system di archiviazione. Se abiliti questa opzione, RDS esegue la migrazione del database verde dal file system di archiviazione precedente alla configurazione preferita. Questa opzione è disponibile solo se il database blu *non* utilizza la configurazione di archiviazione più recente o se stai abilitando Scritture ottimizzate per RDS all'interno della stessa richiesta. È possibile aggiornare la configurazione di storage solo quando si crea inizialmente una distribuzione. blue/green Per ulteriori informazioni, consulta [Aggiornamento del file system di archiviazione per un'istanza database](USER_PIOPS.UpgradeFileSystem.md). | **Opzione CLI:** `--upgrade-target-storage-config` **Parametro API RDS:** `UpgradeTargetStorageConfig` |
| Velocità di trasmissione effettiva per archiviazione | Il valore del throughput di archiviazione per il database verde. Questa impostazione è visibile solo se scegli SSD per scopi generici (gp3) come tipo di archiviazione. Questo valore si applica solo all’istanza database primaria verde, non alle repliche verdi. Per ulteriori informazioni, consulta [Archiviazione gp3 (consigliata)](CHAP_Storage.md#gp3-storage). | **Opzione CLI:** `--target-storage-throughput` **Parametro API RDS:** `TargetStorageThroughput` |
| Storage Type (Tipo di storage) | Il tipo di archiviazione per il database verde. Sono supportati i seguenti tipi di archiviazione: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/blue-green-deployments-creating.html) Questo valore si applica solo all’istanza database primaria verde, non alle repliche verdi. Per ulteriori informazioni, consulta [Tipi di storage Amazon RDS](CHAP_Storage.md#Concepts.Storage). | **Opzione CLI:** `--target-storage-type` **Parametro API RDS:** `TargetStorageType` |
# Visualizzazione di un’implementazione blu/verde in Amazon RDS
È possibile visualizzare i dettagli di un'implementazione blu/verde utilizzando la Console di gestione AWS, AWS CLI o l'API RDS.
È anche possibile visualizzare e sottoscrivere gli eventi per informazioni su un'implementazione blu/verde. Per ulteriori informazioni, consulta [Eventi di implementazione blu/verde](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments).
## Console
**Per visualizzare i dettagli di un'implementazione blu/verde**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione, scegli **Databases** (Database), quindi trova l'implementazione blu/verde nell'elenco.
![\[Implementazione blu/verde nell'elenco dei database\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment-view-db-list.png)
Il valore **Role** (Ruolo) per l'implementazione blu/verde è **Blue/Green Deployment** (Implementazione blu/verde).
1. Scegli il nome dell'implementazione blu/verde di cui desideri visualizzarne i dettagli.
Ogni scheda ha una sezione per l'implementazione blu e una sezione per l'implementazione verde. Ad esempio, nella scheda **Configurazione**, la versione del motore di database potrebbe essere diversa nell’ambiente blu e nell’ambiente verde, se si aggiorna la versione del motore di database nell’ambiente verde.
L’immagine seguente mostra un esempio della scheda **Connettività e sicurezza**.
![\[Dettagli dell'implementazione blu/verde\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment-view-details.png)
La scheda **Connettività e sicurezza** include anche una sezione chiamata **Replica** che mostra lo stato attuale della replica e il ritardo della replica tra gli ambienti blu e verde. Se lo stato di replica è `Replicating`, l'implementazione blu/verde viene replicata correttamente.
Per le implementazioni blu/verde RDS per PostgreSQL che utilizzano la replica logica, lo stato di replica può cambiare in `Replication degraded` se si apportano modifiche DDL non supportate o a oggetti di grandi dimensioni nell’ambiente blu. Per ulteriori informazioni, consulta [Limitazioni specifiche della replica logica per le distribuzioni blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).
L’immagine seguente mostra un esempio della scheda **Configurazione**.
![\[Dettagli della configurazione dell'implementazione blu/verde\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment-view-config.png)
L’immagine seguente mostra un esempio della scheda **Stato**.
![\[Stato dell'implementazione blu/verde\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment-view-status.png)
## AWS CLI
Per visualizzare i dettagli di un'implementazione blu/verde utilizzando AWS CLI, usa il comando [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html).
**Example Visualizzazione dei dettagli di un'implementazione blu/verde filtrando per nome**
Quando si usa il comando [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html), è possibile filtrare in base a `--blue-green-deployment-name`.
L'esempio seguente mostra i dettagli per un'implementazione blu/verde denominata `my-blue-green-deployment`.
```
aws rds describe-blue-green-deployments \
--filters Name=blue-green-deployment-name,Values=my-blue-green-deployment
```
**Example Visualizzazione dei dettagli di un'implementazione blu/verde specificando l'identificatore**
Quando si utilizza il comando [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html), è possibile specificare l’opzione `--blue-green-deployment-identifier`.
L'esempio seguente mostra i dettagli per un'implementazione blu/verde con l'identificatore `bgd-1234567890abcdef`.
```
aws rds describe-blue-green-deployments \
--blue-green-deployment-identifier bgd-1234567890abcdef
```
## API RDS
Per visualizzare i dettagli su un'implementazione blu/verde utilizzando l'API Amazon RDS, utilizza l'operazione [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeBlueGreenDeployments.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeBlueGreenDeployments.html) e specifica `BlueGreenDeploymentIdentifier`.
# Cambiare una blue/green distribuzione in Amazon RDS
Lo *switchover* passa l’ambiente verde come nuovo ambiente di produzione. Se l’istanza database verde include repliche di lettura, anche queste vengono passate. Prima dello switchover, il traffico di produzione viene indirizzato all'istanza database e alle repliche di lettura nell'ambiente blu. Dopo lo switchover, il traffico di produzione viene indirizzato all'istanza database e alle repliche di lettura nell'ambiente verde.
*Cambiare* una blue/green distribuzione non equivale a *promuovere* il all'interno della blue/green distribuzione. Se si promuove manualmente il scegliendo **Promuovi** dal menu **Azioni**, la replica tra gli ambienti blu e verde si interrompe e la blue/green distribuzione entra in uno stato di configurazione **non valida**.
**Topics**
+ [Timeout dello switchover](#blue-green-deployments-switching-timeout)
+ [Guardrail dello switchover](#blue-green-deployments-switching-guardrails)
+ [Azioni dello switchover](#blue-green-deployments-switching-actions)
+ [Best practice per lo switchover](#blue-green-deployments-switching-best-practices)
+ [CloudWatch Verifica delle metriche prima del passaggio al digitale](#blue-green-deployments-switching-over-cloudwatch)
+ [Monitoraggio del ritardo della replica prima dello switchover](#blue-green-deployments-monitor-replica-lag)
+ [Passaggio blue/green da una distribuzione all'altra](#blue-green-deployments-switching-over)
+ [Dopo lo switchover](#blue-green-deployments-switching-after)
## Timeout dello switchover
È possibile specificare un timeout per lo switchover compreso tra 30 secondi e 3.600 secondi (un'ora). Se lo switchover richiede più tempo della durata specificata, viene eseguito il rollback di tutte le modifiche e non viene apportata alcuna modifica agli ambienti. L'impostazione predefinita del timeout è 300 secondi (cinque minuti).
## Guardrail dello switchover
Quando avvii uno switchover, Amazon RDS esegue alcuni controlli di base per verificare la preparazione degli ambienti blu e verdi per lo switchover. Questi controlli sono noti come *guardrail dello switchover* e impediscono lo switchover se gli ambienti non sono pronti per farlo. Pertanto, evitano tempi di inattività più lunghi del previsto e impediscono la perdita di dati tra gli ambienti blu e quelli verdi che potrebbe verificarsi se lo switchover venisse avviato.
Amazon RDS esegue i seguenti controlli guardrail sull'ambiente verde:
+ **Integrità della replica**: verifica se lo stato della replica dell'istanza database primaria verde è integro. L'istanza database primaria verde è una replica dell'istanza database primaria blu.
+ **Ritardo della replica**: verifica se il ritardo della replica dell'istanza database primaria verde rientra nei limiti consentiti per lo switchover. I limiti consentiti si basano sul periodo di timeout specificato. Il ritardo della replica indica il ritardo dell'istanza database primaria verde rispetto all'istanza database primaria blu. Per ulteriori informazioni, consulta [Monitoraggio del ritardo della replica prima dello switchover](#blue-green-deployments-monitor-replica-lag).
+ **Scritture attive**: assicura che non vi siano scritture attive nell'istanza database primaria verde.
Amazon RDS esegue i seguenti controlli guardrail sull'ambiente blu:
+ **Replica esterna**: per RDS per PostgreSQL, assicura che l’ambiente blu non sia un’origine logica autogestita (publisher) o una replica (subscriber). In caso contrario, è consigliabile eliminare gli slot e gli abbonamenti di replica autogestiti su tutti i database nell’ambiente blu, procedere con lo switchover e quindi ricrearli per riprendere la replica. Per RDS per MySQL e RDS per MariaDB, verifica che il database blu non sia una replica di log binari esterna. In caso contrario, è necessario assicurarsi che la replica non sia attiva.
+ **Scritture attive di lunga durata**: assicura che non vi siano scritture attive di lunga durata nell'istanza database primaria blu perché possono aumentare il ritardo della replica.
+ **Istruzioni DDL di lunga durata**: assicura che non vi siano istruzioni DLL di lunga durata nell'istanza database primaria blu perché possono aumentare il ritardo della replica.
+ **Modifiche PostgreSQL non supportate**: per le implementazioni di PostgreSQL RDS blue/green per PostgreSQL che utilizzano la replica logica, assicura che non siano state eseguite modifiche DDL e aggiunte o modifiche di oggetti di grandi dimensioni nell'ambiente blu. Per ulteriori informazioni, consulta [Limitazioni specifiche della replica logica per le distribuzioni blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).
Se Amazon RDS rileva modifiche PostgreSQL non supportate, modifica lo stato di replica e notifica che lo switchover non è disponibile `Replication degraded` per la distribuzione. blue/green Per procedere con il passaggio al digitale, ti consigliamo di eliminare e ricreare la distribuzione e tutti i database ecologici. blue/green A tale scopo, scegli **Operazioni**, **Elimina con database verdi**.
## Azioni dello switchover
Quando si passa a una blue/green distribuzione, RDS esegue le seguenti azioni:
1. Esegue controlli guardrail per verificare se gli ambienti blu e verdi sono pronti per lo switchover.
1. Interrompe le nuove operazioni di scrittura nell'istanza database primaria in entrambi gli ambienti.
1. Elimina le connessioni alle istanze database in entrambi gli ambienti e non consente nuove connessioni.
1. Attende che la replica recuperi l'ambiente verde in modo che sia sincronizzato con l'ambiente blu.
1. Rinomina le istanze database in entrambi gli ambienti.
RDS rinomina le istanze database nell'ambiente verde in modo che corrispondano alle istanze database nell'ambiente blu. Ad esempio, supponi che il nome dell'istanza database nell'ambiente blu sia `mydb`. Supponi anche che il nome dell'istanza database corrispondente nell'ambiente verde sia `mydb-green-abc123`. Durante lo switchover, il nome dell'istanza database nell'ambiente verde viene modificato in `mydb`.
RDS rinomina le istanze database nell'ambiente blu aggiungendo `-oldn` al nome corrente, dove `n` è un numero. Ad esempio, supponi che il nome dell'istanza database nell'ambiente blu sia `mydb`. Dopo lo switchover, il nome dell'istanza database diventa `mydb-old1`.
RDS rinomina anche gli endpoint nell'ambiente verde in modo che corrispondano agli endpoint nell'ambiente blu, per non apportare modifiche all'applicazione.
1. Consente le connessioni ai database in entrambi gli ambienti.
1. Consente le operazioni di scrittura nell'istanza database primaria nel nuovo ambiente di produzione.
Dopo lo switchover, l’istanza database primaria di produzione precedente consente operazioni di lettura solo fino a quando non si imposta su `0` il parametro `read_only` (per RDS per MySQL) o il parametro `default_transaction_read_only` (per RDS per PostgreSQL) e si riavvia l’istanza database.
Puoi monitorare lo stato di uno switchover utilizzando Amazon. EventBridge Per ulteriori informazioni, consulta [Eventi di implementazione blu/verde](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments).
Durante il passaggio, i tag dell'ambiente blu sostituiscono tutti i tag sulle risorse nell'ambiente verde. Tutti i tag aggiunti direttamente alle risorse ambientali verdi vengono sovrascritti durante questo processo. Per ulteriori informazioni sui tag, consulta [Etichettatura delle Amazon RDS](USER_Tagging.md).
Se lo switchover inizia e poi si interrompe prima del termine per un qualsiasi motivo, viene eseguito il rollback di tutte le modifiche e non viene apportata alcuna modifica agli ambienti.
## Best practice per lo switchover
Prima di effettuare lo switchover, ti consigliamo vivamente di seguire le best practice completando le seguenti attività:
+ Esegui accuratamente il test delle risorse nell'ambiente verde. Assicurati che funzionino correttamente ed efficacemente.
+ Monitora le CloudWatch metriche Amazon pertinenti. Per ulteriori informazioni, consulta [CloudWatch Verifica delle metriche prima del passaggio al digitale](#blue-green-deployments-switching-over-cloudwatch).
+ Identifica il momento migliore per lo switchover.
Durante lo switchover, le scritture dei database vengono interrotte in entrambi gli ambienti. Identifica il momento in cui il traffico è più basso nell'ambiente di produzione. Le transazioni a lunga durata, come quelle attive DDLs, possono aumentare i tempi di passaggio al digitale, con conseguenti tempi di inattività più lunghi per i carichi di lavoro di produzione.
Se è presente un numero elevato di connessioni sulle istanze DB, sul cluster di database e sulle istanze , valuta la possibilità di ridurle manualmente al minimo necessario per l'applicazione prima di passare alla distribuzione. blue/green Un modo per raggiungere questo obiettivo è creare uno script che monitori lo stato della blue/green distribuzione e inizi a ripulire le connessioni quando rileva che lo stato è cambiato in. `SWITCHOVER_IN_PROGRESS`
+ Assicurati che le istanze database siano nello stato `Available` in entrambi gli ambienti.
+ Assicurati che l'istanza database primaria nell'ambiente verde sia nello stato integro e in grado di replicare.
+ Assicurati che le configurazioni di rete e client non aumentino la cache DNS Time-To-Live (TTL) oltre cinque secondi, che è l'impostazione predefinita per le zone DNS RDS. In caso contrario, le applicazioni continueranno a inviare traffico di scrittura verso l'ambiente blu dopo il passaggio.
+ Assicurati che il caricamento dei dati sia completato prima di effettuare lo switchover. Per ulteriori informazioni, consulta [Lazy loading e inizializzazione dello storage per le implementazioni blue/green](blue-green-deployments-creating.md#blue-green-deployments-creating-lazy-loading).
+ Per le distribuzioni che utilizzano la replica logica, procedi come segue:
+ Esaminare i limiti della replica logica e intraprendere le azioni necessarie prima dello switchover. Per ulteriori informazioni, consulta [Limitazioni specifiche della replica logica per le distribuzioni blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).
+ Eseguire l'operazione `ANALYZE` per aggiornare la tabella `pg_statistics`. Ciò riduce il rischio di problemi di prestazioni dopo lo switchover.
+ Prima di avviare uno switchover di blue/green distribuzione, verifica che l'applicazione non sovrascriva il parametro a livello di sessione. `default_transaction_read_only` Durante lo switchover, questo parametro è impostato `on` su on the green environment writer per impedire le scritture fino al completamento della promozione. Se l'applicazione o le transazioni hanno la precedenza su questa configurazione`off`, l'applicazione potrebbe scrivere dati nell'ambiente verde durante il processo di passaggio. Nel caso in cui lo switchover debba essere ripristinato, queste scritture non sono disponibili nell'ambiente blu e richiedono la risoluzione manuale delle incongruenze dei dati. Si consiglia vivamente di controllare le query dell'applicazione per assicurarsi che rispettino l'impostazione prima di procedere con lo switchover. `default_transaction_read_only`
**Nota**
Durante uno switchover non è possibile modificare le istanze database incluse nello switchover.
## CloudWatch Verifica delle metriche prima del passaggio al digitale
Prima di passare a una blue/green distribuzione, ti consigliamo di verificare valori delle seguenti metriche all'interno Amazon CloudWatch.
+ `DatabaseConnections`— Utilizza questa metrica per stimare il livello di attività della blue/green distribuzione e assicurati che il valore sia a un livello accettabile per la tua implementazione prima di passare alla versione successiva. Se Approfondimenti sulle prestazioni è attivato, `DBLoad` è un parametro più accurato.
Per ulteriori informazioni, consulta [CloudWatch Parametri Amazon per Amazon RDS](rds-metrics.md).
## Monitoraggio del ritardo della replica prima dello switchover
Prima di passare a un' blue/green implementazione, assicurati che il ritardo di replica sia vicino allo zero per ridurre i tempi di inattività.
### RDS per MySQL e RDS per MariaDB
Per le implementazioni MySQL e blue/green MariadB, CloudWatch controlla la metrica nell'ambiente verde per identificare l'attuale ritardo della replica. Per ulteriori informazioni, consulta [Diagnosi e risoluzione del ritardo tra repliche di lettura](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag).
### RDS per PostgreSQL
Per le distribuzioni blue/green PostgreSQL che utilizzano la replica fisica, [Monitoraggio e ottimizzazione del processo di replica](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md) consulta le istruzioni per identificare l'attuale ritardo di replica.
Per le distribuzioni blue/green PostgreSQL che utilizzano la replica logica, controlla la metrica nell'ambiente blu per identificare `OldestReplicationSlotLag` CloudWatch l'attuale ritardo della replica. Per ulteriori informazioni, consulta [Parametri a CloudWatch livello di istanza Amazon per Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
Inoltre, è possibile eseguire la seguente query SQL nell’ambiente blu:
```
SELECT slot_name,
confirmed_flush_lsn as flushed,
pg_current_wal_lsn(),
(pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical';
slot_name | flushed | pg_current_wal_lsn | lsn_distance
-----------------+---------------+--------------------+------------
logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8 | 37192
```
`confirmed_flush_lsn` rappresenta l’ultimo numero di sequenza di log (LSN) inviato alla replica. `pg_current_wal_lsn` rappresenta la posizione attuale del database. Un valore `lsn_distance` pari a 0 significa che la replica è stata recuperata.
Per una spiegazione di quando le blue/green implementazioni utilizzano la replica fisica rispetto alla replica logica, vedi. [Metodi di replica PostgreSQL per le distribuzioni blue/green](blue-green-deployments-replication-type.md)
## Passaggio blue/green da una distribuzione all'altra
È possibile passare da una blue/green distribuzione all'altra utilizzando Console di gestione AWS l' AWS CLI API RDS o l'API RDS.
### Console
**Per passare da una blue/green distribuzione all'altra**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione, scegli **Database**, quindi scegli la blue/green distribuzione che desideri trasferire.
1. In **Actions** (Operazioni), scegli **Switch over** (Esegui switchover).
Viene visualizzata la pagina **Switch over** (Switchover).
![\[Passa alla blue/green distribuzione\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment-switch-over.png)
1. Nella pagina **Switch over** (Switchover), consulta il riepilogo dello switchover. Assicurati che le risorse in entrambi gli ambienti corrispondano a quelle previste. In caso contrario, scegli **Cancel** (Annulla).
1. In **Impostazioni di timeout**, inserisci il limite di tempo per lo switchover.
1. Se sull'istanza è in esecuzione RDS per PostgreSQL, esamina e verifica i suggerimenti prima dello switchover. Per ulteriori informazioni, consulta [Limitazioni specifiche della replica logica per le distribuzioni blue/green](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres).
1. Seleziona **Switch over** (Switchover).
### AWS CLI
Per cambiare una blue/green distribuzione utilizzando il AWS CLI, usa il [switchover-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-blue-green-deployment.html)comando con le seguenti opzioni:
+ `--blue-green-deployment-identifier`— Specificare l'ID della risorsa della blue/green distribuzione.
+ `--switchover-timeout`: specifica il limite di tempo per lo switchover, in secondi. Il valore predefinito è 300.
**Example Passare da una blue/green distribuzione all'altra**
Per Linux, macOS o Unix:
```
aws rds switchover-blue-green-deployment \
--blue-green-deployment-identifier bgd-1234567890abcdef \
--switchover-timeout 600
```
Per Windows:
```
aws rds switchover-blue-green-deployment ^
--blue-green-deployment-identifier bgd-1234567890abcdef ^
--switchover-timeout 600
```
### API RDS
Per passare da una blue/green distribuzione utilizzando l'API Amazon RDS, utilizza l'[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html)operazione con i seguenti parametri:
+ `BlueGreenDeploymentIdentifier`— Specificare l'ID della risorsa della blue/green distribuzione.
+ `SwitchoverTimeout`: specifica il limite di tempo per lo switchover, in secondi. Il valore predefinito è 300.
## Dopo lo switchover
Dopo uno switchover, le istanze database vengono mantenute nell'ambiente blu precedente. A queste risorse si applicano i costi standard. La replica tra gli ambienti blu e verde vengono arrestati.
RDS rinomina le istanze database nell'ambiente blu aggiungendo `-oldn` al nome corrente, dove `n` è un numero. Le istanze database nel vecchio ambiente blue sono di sola lettura finché non si imposta su `0` il parametro `read_only` (per RDS per MySQL) o il parametro `default_transaction_read_only` (per RDS per PostgreSQL). RDS rinomina le istanze database e le istanze database `-newn` in entrambi gli ambienti.
Se si elimina la risorsa blue/green di distribuzione, RDS conserva le risorse and. `-oldn` `-newn`
![\[Dopo il passaggio a una distribuzione blue/green\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment-after-switchover.png)
### Aggiornamento del nodo principale per i consumer
RDS offre repliche di lettura completamente gestite. Tuttavia, fornisce anche la possibilità di configurare repliche autogestite, note anche come *repliche esterne.* Le repliche esterne consentono di utilizzare risorse di terze parti come destinazioni della replica.
Dopo aver cambiato una distribuzione RDS per MariaDB o RDS per MySQL MySQL, se il cluster DB di blu aveva repliche esterne o utenti di log binari prima del passaggio, è necessario aggiornare il nodo principale dopo il passaggio per mantenere la continuità della replica.
**Per aggiornare il nodo principale**
1. Dopo lo switchover, l’istanza database di che si trovava precedentemente nell’ambiente verde emette un evento che contiene il nome del file di log principale e la posizione del log principale. Per individuare l’evento, accedere alla console RDS e scegliere **Eventi** nel riquadro di navigazione a sinistra.
1. Filtra per eventi la cui origine è il nome della vecchia istanza database di verde, prima dello switchover.
1. Individua l’evento che contiene le coordinate del log binario. Il messaggio dell’evento è simile a: `Binary log coordinates in green environment after switchover: file mysql-bin-changelog.000003 and position 40134574`.
1. Assicurati che il consumer o la replica abbiano applicato tutti i log binari del vecchio ambiente blu. Quindi, utilizza le coordinate del log binario fornite per riprendere la replica sui consumer. Ad esempio, se esegui una replica MySQL su EC2, puoi utilizzare i seguenti comandi:
**MySQL 8.0.22 e versioni principali e secondarie precedenti**
```
CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=40134574;
```
**MySQL 8.0.23 e versioni principali e secondarie successive**
```
CHANGE REPLICATION SOURCE TO SOURCE_HOST='{new-writer-endpoint}', SOURCE_LOG_FILE='mysql-bin-changelog.000003', SOURCE_LOG_POS=40134574;
```
Se il consumer è un’altra istanza database RDS per MySQL o RDS per MariaDB, eseguire le seguenti stored procedure nell’ordine:
1. [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication)
1. [mysql.rds\$1reset\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) (per la versione 8.0 e precedenti) o [mysql\$1rds\$1reset\$1external\$1source](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) (per la versione 8.4 e successive)
1. [mysql.rds\$1set\$1external\$1master](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) (per la versione 8.0 e precedenti) o [mysql\$1rds\$1set\$1external\$1source](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) (per la versione 8.4 e successive)
1. [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication)
#
Puoi eliminare una blue/green distribuzione prima o dopo averla cambiata.
Quando elimini una blue/green distribuzione prima di trasferirla, Amazon RDS elimina facoltativamente il di istanze DB nell'ambiente verde:
+ Se scegli di eliminare le istanze database nell'ambiente verde (`--delete-target`), per tali istanze la protezione dall'eliminazione deve essere disattivata.
+ Se non elimini il di istanze DB nell'ambiente verde (`--no-delete-target`), le istanze del mantenute, ma non fanno più parte . blue/green Per RDS per MySQL, la replica continua tra gli ambienti. Per RDS per PostgreSQL, l’ambiente verde viene promosso ad ambiente autonomo, quindi la replica si arresta.
L'opzione per eliminare i database verdi non è disponibile nella console dopo lo [switchover](blue-green-deployments-switching.md). [Quando elimini le distribuzioni blu/verdi utilizzando AWS CLI, non puoi specificare l'opzione se lo stato della `--delete-target` distribuzione è.](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_BlueGreenDeployment.html) `SWITCHOVER_COMPLETED`
**Importante**
L'eliminazione di una blue/green distribuzione non influisce sull'ambiente blu.
È possibile eliminare una blue/green distribuzione utilizzando l'API RDS o Console di gestione AWS l'API AWS CLI RDS.
## Console
**Per eliminare una distribuzione blue/green**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione, scegli **Database**, quindi scegli la blue/green distribuzione che desideri eliminare.
1. In **Actions (Azioni)**, scegliere **Delete (Elimina)**.
La ** blue/green distribuzione Delete?** Viene visualizzata la finestra.
![\[Eliminare blue/green la distribuzione\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/blue-green-deployment-delete.png)
Per eliminare i database verdi, seleziona **Elimina i database verdi in questa blue/green distribuzione**.
1. Immettere **delete me** nella casella.
1. Scegliere **Delete (Elimina)**.
## AWS CLI
Per eliminare una blue/green distribuzione utilizzando il AWS CLI, utilizza il [delete-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-blue-green-deployment.html)comando con le seguenti opzioni:
+ `--blue-green-deployment-identifier`— L'ID della risorsa della blue/green distribuzione da eliminare.
+ `--delete-target`: specifica che le istanze nell'ambiente verde vengono eliminate. Non è possibile specificare questa opzione se lo stato della blue/green distribuzione è di`SWITCHOVER_COMPLETED`.
+ `--no-delete-target`: specifica che le istanze nell'ambiente verde vengono mantenute.
**Example Elimina una blue/green distribuzione e il di istanze DB nell'ambiente verde**
Per Linux, macOS o Unix:
```
aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier bgd-1234567890abcdef \
--delete-target
```
Per Windows:
```
aws rds delete-blue-green-deployment ^
--blue-green-deployment-identifier bgd-1234567890abcdef ^
--delete-target
```
**Example Eliminare una blue/green distribuzione ma conservare il di istanze DB nell'ambiente verde**
Per Linux, macOS o Unix:
```
aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier bgd-1234567890abcdef \
--no-delete-target
```
Per Windows:
```
aws rds delete-blue-green-deployment ^
--blue-green-deployment-identifier bgd-1234567890abcdef ^
--no-delete-target
```
## API RDS
Per eliminare una blue/green distribuzione utilizzando l'API Amazon RDS, utilizza l'[https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteBlueGreenDeployment.html)operazione con i seguenti parametri:
+ `BlueGreenDeploymentIdentifier`— L'ID della risorsa della blue/green distribuzione da eliminare.
+ `DeleteTarget`: specifica `TRUE` per eliminare le istanze nell'ambiente verde o `FALSE` per mantenerle. Non può essere `TRUE` se lo stato dell'implementazione blu/verde è `SWITCHOVER_COMPLETED`.