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à.
# Best practice per le implementazioni di Amazon Aurora 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)
+ [per le implementazioni blue/green](#blue-green-deployments-best-practices-mysql)
+ [Best practice di Aurora PostgreSQL per le implementazioni blue/green](#blue-green-deployments-best-practices-postgres)
+ [Aurora Global Database: best practice per le implementazioni blue/green](#blue-green-deployments-best-practices-agd)
## 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 del cluster di database Aurora 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.
+ Usa l'endpoint del cluster, l'endpoint di lettura o l'endpoint personalizzato per tutte le connessioni in entrambi gli ambienti. Non utilizzare endpoint di istanza o endpoint personalizzati con gli elenchi statici o di esclusione.
+ Quando passi da una blue/green distribuzione all'altra, segui le migliori pratiche di commutazione. Per ulteriori informazioni, consulta [Best practice per lo switchover](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices).
## per le implementazioni blue/green
Prendi in considerazione le seguenti best practice quando crei una blue/green distribuzione da un cluster .
+ Se l’ambiente verde presenta un ritardo di replica, considera i seguenti requisiti:
+ Disabilita la conservazione dei log binari se non è necessaria o disabilitala temporaneamente fino al recupero della replica. A tale scopo, reimposta il parametro del cluster di database `binlog_format` su `0` e riavvia l’istanza database di scrittura verde.
+ Imposta temporaneamente il parametro `innodb_flush_log_at_trx_commit` su `0` 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 ulteriori informazioni, consulta [Configurazione della frequenza di svuotamento del buffer dei registri](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush).
## Best practice di Aurora PostgreSQL per le implementazioni blue/green
Prendi in considerazione le seguenti best practice quando crei una blue/green distribuzione da un cluster Aurora PostgreSQL DB.
+ Monitora la cache write-through della replica logica di Aurora PostgreSQL e apporta modifiche al buffer della cache, se necessario. Per ulteriori informazioni, consulta [Monitoraggio della cache di scrittura della replica logica di Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache).
+ 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, consulta [Regolazione della memoria di lavoro per la decodifica logica](AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.md#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem).
+ È possibile monitorare l'overflow delle transazioni 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 livello di istanza per Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
+ In Aurora 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)`.
+ Aggiorna tutte le estensioni PostgreSQL alla versione più recente prima di creare una distribuzione. blue/green Per ulteriori informazioni, consulta [Aggiornamento estensioni PostgreSQL](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md).
+ Se utilizzi l’estensione `aws_s3`, assicurati di fornire al cluster di 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).
+ 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 [Esecuzione di un aggiornamento alla versione principale](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.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.
+ 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 e le transazioni secondarie 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 istruzioni, consulta [Esecuzione di un congelamento manuale del vacuum](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.html).
+ In PostgreSQL 12 e versioni successive, disabilita il parametro `index_cleanup` sulle tabelle di grandi dimensioni o particolarmente utilizzate per migliorare l’efficienza della manutenzione regolare dei database blu. Per ulteriori informazioni, consulta [Vacuum di una tabella il più rapidamente possibile](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#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.
+ Il ritardo di replica può verificarsi se le istanze database blu e verdi sono sottodimensionate per il carico di lavoro. Assicurati che le istanze database non raggiungano i limiti di risorse per il tipo di istanza. Per ulteriori informazioni, consulta [Utilizzo dei CloudWatch parametri di Amazon per analizzare l'utilizzo delle risorse per Aurora PostgreSQL](AuroraPostgreSQL_AnayzeResourceUsage.md).
+ 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.
+ 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. Per ulteriori informazioni, consulta [Controlla i filtri predicati per le query che generano attese](apg-waits.iodatafileread.md#apg-waits.iodatafileread.actions.filters).
+ 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 Babelfish è abilitato sul cluster di database di origine, i seguenti parametri devono avere nel gruppo di parametri del cluster di database di destinazione per l’ambiente verde le stesse impostazioni del gruppo di parametri del cluster di database di origine:
+ rds.babelfish\$1status
+ babelfishpg\$1tds.tds\$1default\$1numeric\$1precision
+ babelfishpg\$1tds.tds\$1default\$1numeric\$1scale
+ babelfishpg\$1tsql.default\$1locale
+ babelfishpg\$1tsql.migration\$1mode
+ babelfishpg\$1tsql.server\$1collation\$1name
Per ulteriori informazioni su questi parametri, consultare [Impostazioni del gruppo di parametri del cluster database per Babelfish](babelfish-configuration.md).
## Aurora 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'istanza 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