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 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 migliori pratiche 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.