Best practice per le distribuzioni Amazon Aurora - Amazon Aurora
Le migliori pratiche generali per le implementazioni blu/verdi per implementazioni blu/greenLe migliori pratiche di Aurora PostgreSQL per implementazioni blu/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 distribuzioni Amazon Aurora

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

Le migliori pratiche generali per le implementazioni blu/verdi

Prendi in considerazione le seguenti best practice generali quando crei una distribuzione 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 distribuzione blu/verde per implementare le 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 dalla distribuzione blu a quella 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 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.

per implementazioni blu/green

Prendi in considerazione le seguenti best practice quando crei una distribuzione blu/verde da un cluster Aurora .

  • Se l'ambiente verde presenta un ritardo di replica, considera quanto segue:

    • Disabilita la conservazione dei log binari se non è necessaria o disabilitala temporaneamente fino a quando la replica non viene ripristinata. A tale scopo, reimposta il parametro del cluster binlog_format DB su 0 e riavvia l'istanza DB green writer.

    • Imposta temporaneamente il innodb_flush_log_at_trx_commit parametro nel gruppo di parametri DB verde. Una volta ripristinata la replica, ripristinate il valore predefinito di prima dello switchover. 1 Se si verifica un arresto imprevisto o un arresto anomalo con il valore temporaneo del parametro, ricostruisci l'ambiente verde per evitare il danneggiamento dei dati non rilevato. Per ulteriori informazioni, consulta Configurazione della frequenza di svuotamento del buffer dei registri.

Le migliori pratiche di Aurora PostgreSQL per implementazioni blu/green

Prendi in considerazione le seguenti best practice quando crei una distribuzione blu/verde 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 write-through della replica logica di Aurora Postgree SQL.

  • Aumenta il valore del parametro logical_decoding_work_mem DB 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 in fase di scrittura su disco utilizzando la ReplicationSlotDiskUsage CloudWatch metrica. Questa metrica offre informazioni sull'utilizzo del disco degli slot di replica, aiutando a identificare 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 versione 14 e successive, è possibile monitorare la dimensione dei file di overflow logico utilizzando la vista di sistema. pg_stat_replication_slots

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

  • Se utilizzi l'aws_s3estensione, consenti al cluster DB 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, consultare Configurazione dell'accesso a un bucket Amazon S3.

  • Se specifichi una versione superiore del motore per l'ambiente verde, esegui l'ANALYZEoperazione su tutti i database per aggiornare la pg_statistic tabella. Le statistiche di Optimizer non vengono trasferite durante l'aggiornamento di una versione principale, quindi è necessario rigenerare tutte le statistiche per evitare problemi di prestazioni. Per ulteriori procedure consigliate durante gli aggiornamenti delle versioni principali, consulta. Esecuzione di un aggiornamento della versione principale

  • Evita di configurare i trigger ENABLE ALWAYS se ENABLE REPLICA o se il trigger viene utilizzato sulla fonte per manipolare i dati. In caso contrario, il sistema di replica propaga le modifiche ed esegue il trigger, che porta alla duplicazione.

  • Le transazioni di lunga durata possono causare un notevole ritardo nella replica. Per ridurre il ritardo di replica, prova a fare quanto segue:

    • Riduci le transazioni di lunga durata e le sottotransazioni 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 tavoli occupati prima di creare la distribuzione blu/verde. Per istruzioni, vedere Esecuzione di un congelamento sottovuoto manuale.

    • Nella versione 12 di PostgreSQL e successive, disabilita index_cleanup il parametro su tabelle di grandi dimensioni o occupate per migliorare l'efficienza della manutenzione regolare dei database blu. Per ulteriori informazioni, consulta Aspirare una tabella il più rapidamente possibile.

      Nota

      Saltare regolarmente la pulizia dell'indice durante l'aspirazione può causare un aumento dell'indice, che potrebbe compromettere le prestazioni di scansione. Come procedura ottimale, utilizzate questo approccio solo quando utilizzate una distribuzione blu/verde. Una volta completata la distribuzione, consigliamo di riprendere la manutenzione e la pulizia regolari dell'indice.

    • Il ritardo nella replica può verificarsi se le istanze DB blu e verdi sono sottodimensionate per il carico di lavoro. Assicurati che le tue istanze DB 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 assicurarvi che rimangano attivi, disattivate i timeout impostando il wal_sender_timeout parametro su 0 nell'ambiente blu e il parametro su nell'ambiente verde. wal_receiver_timeout 0

  • 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. Ciò 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 pg_catalog.pg_publication pg_catalog.pg_replication_slots oggetti i cui nomi iniziano con «rds». pg_catalog.pg_subscription

  • Se Babelfish è abilitato sul cluster DB di origine, i seguenti parametri devono avere le stesse impostazioni nel gruppo di parametri del cluster DB di destinazione per l'ambiente verde come nel gruppo di parametri del cluster DB 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.