Best practice per le implementazioni blu/verdi di Amazon RDS - Amazon Relational Database Service
Best practice generali per le implementazioni blu/verdiBest practice per implementazioni blu/verdi di RDS per MySQLBest practice di RDS per PostgreSQL per le implementazioni blu/verdi

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 blu/verdi di Amazon RDS

Di seguito sono riportate le best practice per le implementazioni blu/verdi.

Best practice generali per le implementazioni blu/verdi

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 un’implementazione blu/verde per implementare le modifiche dello schema, effettua 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 nella documentazione MySQL e Restrictions nella documentazione della replica logica PostgreSQL.

    Nota

    Questa limitazione non si applica alle implementazioni blu/verdi di RDS per PostgreSQL che utilizzano la replica fisica. Per ulteriori informazioni, consulta Limitazioni di RDS per PostgreSQL per le implementazioni con replica fisica blue/green .

  • Dopo aver creato l'implementazione blu/verde, gestisci il caricamento lento, se necessario. Assicurati che il caricamento dei dati sia completato prima di effettuare lo switchover. Per ulteriori informazioni, consulta Caricamento lento e inizializzazione dell’archiviazione per le implementazioni blu/verde.

  • Quando si effettua lo switchover in una implementazione blu/verde, attenersi alle best practice relative allo switchover. Per ulteriori informazioni, consulta Best practice per lo switchover.

Best practice per implementazioni blu/verdi di RDS per MySQL

Le seguenti best practice si utilizzano quando si crea un’implementazione blu/verde da un’istanza database RDS per MySQL.

  • 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 motore di database, abilita la replica GTID, parallela e protetta da arresto anomalo per garantire la durabilità e la coerenza dei dati prima di creare l’implementazione blu/verde. Per ulteriori informazioni, consulta Utilizzo della replica basata su GTID.

  • 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.

Best practice di RDS per PostgreSQL per le implementazioni blu/verdi

Le seguenti best practice si utilizzano quando si crea un’implementazione blu/verde da un’istanza database RDS per PostgreSQL.

Best practice generali di RDS per PostgreSQL per le implementazioni blu/verde

Le seguenti best practice generali si utilizzano quando si crea un’implementazione blu/verde da un’istanza database RDS per PostgreSQL.

  • Aggiorna tutte le estensioni di PostgreSQL all'ultima versione prima di creare un'implementazione blu/verde. Per ulteriori informazioni, consulta Aggiornamento delle estensioni PostgreSQL nei database RDS per PostgreSQL.

  • 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 di congelamento manuale del vacuum sulle tabelle particolarmente utilizzate prima di creare l’implementazione blu/verde.

    • 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.

      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, utilizza questo approccio solo con un’implementazione blu/verde. 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 di RDS per PostgreSQL per le implementazioni blu/verde con replica fisica

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.

Per una spiegazione di quando le implementazioni blu/verde utilizzano la replica fisica anziché la replica logica, consulta Metodi di replica PostgreSQL per le implementazioni blu/verde.

Best practice di RDS per PostgreSQL per le implementazioni blu/verde con replica logica

Le seguenti best practice si utilizzano quando si crea un’implementazione blu/verde che utilizza la replica logica. Per una spiegazione di quando le implementazioni blu/verde utilizzano la replica logica anziché la replica fisica, consulta Metodi di replica PostgreSQL per le implementazioni blu/verde.

  • 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.

    • È possibile monitorare l’overflow delle transazioni scritte su disco utilizzando la metrica CloudWatch ReplicationSlotDiskUsage. 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. Puoi monitorare la memoria liberabile con il parametro CloudWatch FreeableMemory. Per ulteriori informazioni, consulta Parametri a livello di istanza di Amazon CloudWatch per Amazon RDS.

    • In RDS per PostgreSQL 14 e versioni successive, è possibile monitorare la dimensione dei file di overflow logico utilizzando la visualizzazione di sistema pg_stat_replication_slots.

  • 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.

  • 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.

  • 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.