Best practice per le implementazioni di Amazon Aurora blue/green - Amazon Aurora
Procedure consigliate generali per le implementazioni blue/green per le implementazioni blue/green Best practice di Aurora PostgreSQL per le implementazioni blue/green Aurora Global Database: best practice per le implementazioni blue/green

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

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 nella documentazione MySQL e Restrictions 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.

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.

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.

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

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

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

  • Aggiorna tutte le estensioni PostgreSQL alla versione più recente prima di creare una distribuzione. blue/green Per ulteriori informazioni, consulta Aggiornamento estensioni PostgreSQL.

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

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

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

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

      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.

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

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

    • babelfishpg_tds.tds_default_numeric_precision

    • babelfishpg_tds.tds_default_numeric_scale

    • babelfishpg_tsql.default_locale

    • babelfishpg_tsql.migration_mode

    • babelfishpg_tsql.server_collation_name

    Per ulteriori informazioni su questi parametri, consultare Impostazioni del gruppo di parametri del cluster database per Babelfish.

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