Best practice per le distribuzioni blu/verde di Amazon RDS Aurora - Amazon Relational Database Service
Le migliori pratiche generali per le implementazioni blu/verdiRDS per MySQL : best practice MySQL per implementazioni blu/greenBest practice RDS per 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 blu/verde di Amazon RDS 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 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 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.

    Nota

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

  • 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 Lazy loading e inizializzazione dello storage per implementazioni blu/green.

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

RDS per MySQL : best practice MySQL per implementazioni blu/green

  • 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 ecologico per la replica dei 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 tua implementazione blu/green. Per ulteriori informazioni, consulta Utilizzo della replica GTID basata.

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

    • Imposta temporaneamente il innodb_flush_log_at_trx_commit parametro 2nel 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 ridurre la latenza di scrittura e migliorare la velocità di replica, modifica temporaneamente le istanze DB Multi-AZ verdi in istanze DB Single-AZ. Riattiva Multi-AZ subito prima del passaggio.

Best practice RDS per PostgreSQL per implementazioni blu/green

Prendi in considerazione le seguenti best practice quando crei una distribuzione blu/verde da un'istanza DB RDS per PostgreSQL.

Best practice generali di RDS per PostgreSQL per implementazioni blu/green

Prendi in considerazione le seguenti best practice generali quando crei una distribuzione blu/verde da un'istanza DB 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 SQL estensioni Postgre nei database Postgre RDS SQL.

  • 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 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 PostgreSQL versione 12 e successive, disabilita index_cleanup il parametro su tabelle di grandi dimensioni o occupate per aumentare la frequenza di manutenzione normale sui database blu. Per ulteriori informazioni, consulta Vacuum di una tabella il più rapidamente possibile.

      Nota

      Saltare regolarmente la pulizia dell'indice durante la pulizia dell'indice può causare un aumento del volume dell'indice, che potrebbe ridurre 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.

  • 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

  • Per evitare che i segmenti write-ahead log (WAL) vengano rimossi dall'ambiente blu, imposta il wal_keep_segments parametro su 15625 per PostgreSQL versione 13 e precedenti. Per la versione 14 e successive, imposta il wal_keep_size parametro su 1 TiB, se c'è abbastanza spazio di archiviazione libero.

Best practice RDS per PostgreSQL per implementazioni blu/green con replica fisica

Con la replica fisica, Amazon RDS crea una replica di lettura dell'istanza DB 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/green utilizzano la replica fisica anziché la replica logica, vedere. Metodi di SQL replica Postgree per implementazioni blu/verdi

Best practice RDS per PostgreSQL per implementazioni blu/green con replica logica

Prendi in considerazione le seguenti best practice: quando crei una blue/green deployment that uses logical replication. For an explanation of when blue/green distribuzione, utilizza la replica logica anziché la replica fisica, vedi. Metodi di SQL replica Postgree per implementazioni blu/verdi

  • Se il database dispone di memoria disponibile sufficiente, aumentate 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, consultare la documentazione di PostgreSQL.

    • È possibile monitorare l'overflow delle transazioni che vengono scritte 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 CloudWatch livello di istanza Amazon per Amazon RDS.

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

  • Se utilizzi l'aws_s3estensione, consenti all'istanza DB verde di accedere 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.

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

  • 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 specifichi una versione superiore del motore per l'ambiente verde, esegui l'ANALYZEoperazione su tutti i database per aggiornare la tabella. pg_statistic 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. Come eseguire un aggiornamento della versione principale di RDS Postgre SQL

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