Utilizzo della replica logica per eseguire l'aggiornamento a una versione principale per Aurora PostgreSQL

L'utilizzo della replica logica e della clonazione rapida Aurora consente di eseguire un aggiornamento della versione principale che utilizza la versione corrente del database Aurora PostgreSQL mentre si esegue gradualmente la migrazione dei dati modificati nel nuovo database della versione principale. Questo processo di aggiornamento con tempi di inattività ridotti viene definito aggiornamento blu/verde. La versione corrente del database è denominata ambiente "blu" e la nuova versione del database è denominata ambiente "verde".

La clonazione rapida di Aurora carica completamente i dati esistenti generando uno snapshot del database di origine. La clonazione rapida utilizza un copy-on-write protocollo basato sul livello di archiviazione Aurora, che consente di creare un clone del database in breve tempo. Questo metodo è molto efficace quando si esegue l'aggiornamento a un database di grandi dimensioni.

La replica logica in PostgreSQL monitora e trasferisce le modifiche ai dati dall'istanza iniziale a una nuova istanza in esecuzione in parallelo fino al passaggio alla versione più recente di PostgreSQL. La replica logica utilizza un modello di pubblicazione e sottoscrizione. Per ulteriori informazioni sulla replica logica di Aurora PostgreSQL, consulta Replica con Amazon Aurora PostgreSQL.

Suggerimento

Puoi ridurre al minimo i tempi di inattività necessari per l'aggiornamento di una versione principale utilizzando la funzionalità gestita di Amazon RDS Blue/Green Deployment. Per ulteriori informazioni, consulta Utilizzo delle implementazioni blu/verde Amazon RDS per gli aggiornamenti del database.

Requisiti

È necessario soddisfare i seguenti requisiti per eseguire questo processo di aggiornamento con tempi di inattività ridotti:

• È necessario disporre delle autorizzazioni rds_superuser.

• Il cluster database Aurora PostgreSQL da aggiornare deve eseguire una versione supportata in grado di eseguire aggiornamenti di versione principali utilizzando la replica logica. Assicurarsi di applicare eventuali aggiornamenti e patch della versione secondaria al cluster database in uso. La funzione aurora_volume_logical_start_lsn utilizzata in questa tecnica è supportata nelle seguenti versioni di Aurora PostgreSQL:

  • 15.2 o versioni successive alla 15

  • 14.3 o versioni successive alla 14

  • 13.6 o versioni successive alla 13

  • 12.10 e versioni successive alla 12

  • 11.15 e versioni successive alla 11

  • 10.20 e versioni successive alla 10

  Per ulteriori informazioni sulla funzione aurora_volume_logical_start_lsn consulta aurora_volume_logical_start_lsn.

• Tutte le tabelle devono avere una chiave primaria o includere una colonna di identità PostgreSQL.

• Configura il gruppo di sicurezza per il VPC in modo da consentire l'accesso in entrata e in uscita tra i due cluster di database Aurora PostgreSQL, vecchio e nuovo. Puoi autorizzare l'accesso a un intervallo di instradamento interdominio senza classi (CIDR) specifico o a un altro gruppo di sicurezza nel tuo VPC o in un VPC in peering. Il VPC in peering richiede una connessione peering VPC.

Nota

Per informazioni dettagliate sulle autorizzazioni necessarie per configurare e gestire uno scenario di replica logica in esecuzione, consulta la documentazione principale di PostgreSQL.

Limitazioni

Quando si esegue l'aggiornamento con tempi di inattività ridotti del cluster database Aurora PostgreSQL a una nuova versione principale, si utilizza la funzionalità di replica logica nativa di PostgreSQL. Ha le stesse capacità e limitazioni della replica logica di PostgreSQL. Per ulteriori informazioni, consulta la pagina relativa alla replica logica di PostgreSQL.

• I comandi DDL (Data Definition Language) non vengono replicati.

• La replica non supporta le modifiche dello schema in un database attivo. Lo schema viene ricreato nel suo formato originale durante il processo di clonazione. Se si modifica lo schema dopo la clonazione, ma prima di completare l'aggiornamento, la modifica non si riflette nell'istanza aggiornata.

• Gli oggetti di grandi dimensioni non vengono replicati, ma è possibile archiviare i dati in tabelle normali.

• La replica è supportata solo dalle tabelle, comprese le tabelle partizionate. La replica su altri tipi di relazioni, come viste, viste materializzate o tabelle esterne, non è supportata.

• I dati della sequenza non vengono replicati e richiedono l'aggiornamento manuale dopo il failover.

Nota

Questo aggiornamento non supporta l'elaborazione automatica di script. È necessario eseguire tutti i passaggi manualmente.

Impostazione e controllo dei valori dei parametri

Prima dell'aggiornamento, configura l'istanza di scrittura del cluster di database Aurora PostgreSQL in modo che agisca da server di pubblicazione. L'istanza deve utilizzare un gruppo di parametri del·cluster di database personalizzato con le seguenti impostazioni:

• rds.logical_replication: imposta questo parametro su 1. Il parametro rds.logical_replication ha lo stesso scopo del parametro wal_level di un server PostgreSQL autonomo e di altri parametri che controllano la gestione dei file WAL (write-ahead log).

• max_replication_slots: imposta questo parametro sul numero totale di sottoscrizioni che intendi creare. Se la utilizzi AWS DMS, imposta questo parametro sul numero di AWS DMS attività che intendi utilizzare per l'acquisizione di dati modificati da questo cluster DB.

• max_wal_senders: imposta il numero di connessioni simultanee, più qualcuna extra, da rendere disponibili per le attività di gestione e le nuove sessioni. Se lo stai utilizzando AWS DMS, il numero di max_wal_senders deve essere uguale al numero di sessioni simultanee più il numero di AWS DMS attività che potrebbero funzionare in un dato momento.

• max_logical_replication_workers: imposta il numero di worker di replica logica e di sincronizzazione delle tabelle previsti. In genere è sicuro impostare il numero di worker di replica sullo stesso valore utilizzato per max_wal_senders. I worker vengono presi dal pool dei processi in background (max_worker_processes) allocati per il server.

• max_worker_processes: imposta il numero di processi in background per il server. Questo numero deve essere sufficientemente grande da assegnare i worker alla replica, ai processi di pulizia automatica e ad altri processi di manutenzione che possono avvenire contemporaneamente.

Quando si esegue l'aggiornamento a una versione più recente di Aurora PostgreSQL, è necessario duplicare tutti i parametri modificati nella versione precedente del gruppo di parametri. Questi parametri vengono applicati alla versione aggiornata. Puoi eseguire query sulla tabella pg_settings per ottenere l'elenco delle impostazioni dei parametri in modo da poterle ricreare nel tuo nuovo cluster di database Aurora PostgreSQL.

Ad esempio, per ottenere le impostazioni per i parametri di replica, esegui la query riportata di seguito:

SELECT name, setting FROM pg_settings WHERE name in 
('rds.logical_replication', 'max_replication_slots', 
'max_wal_senders', 'max_logical_replication_workers', 
'max_worker_processes');

Aggiornamento di Aurora PostgreSQL a una nuova versione principale

Per preparare l'entità di pubblicazione (blu)

1. Nell'esempio che segue, l'istanza di scrittura di origine (blu) è un cluster di database Aurora PostgreSQL che esegue PostgreSQL versione 11.15. È il nodo di pubblicazione nel nostro scenario di replica. Per questa dimostrazione, l'istanza di scrittura di origine ospita una tabella di esempio che contiene una serie di valori:

   CREATE TABLE my_table (a int PRIMARY KEY);
   INSERT INTO my_table VALUES (generate_series(1,100));

2. Per creare una pubblicazione nell'istanza di origine, connettiti al nodo di scrittura dell'istanza con psql (l'interfaccia della linea di comando per PostgreSQL) o con il client di tua scelta. Immetti il comando seguente in ogni database:

   CREATE PUBLICATION publication_name FOR ALL TABLES;

   L'indicazione publication_name specifica il nome della pubblicazione.

3. È inoltre necessario creare uno slot di replica nell'istanza. Il comando seguente crea uno slot di replica e carica il plug-in di decodifica logica pgoutput. Il plug-in modifica il contenuto letto da WAL (write-ahead log) al protocollo di replica logica e filtra i dati in base alle specifiche di pubblicazione.

   SELECT pg_create_logical_replication_slot('replication_slot_name', 'pgoutput');

Per clonare l'entità di pubblicazione

1. Utilizza la console Amazon RDS per creare un clone dell'istanza di origine. Evidenzia il nome dell'istanza nella console Amazon RDS, quindi scegli Create clone (Crea clone) nel menu Actions (Operazioni).

   

2. Specifica un nome univoco per l'istanza. La maggior parte delle impostazioni sono quelle predefinite dell'istanza di origine. Dopo aver apportato le modifiche necessarie per la nuova istanza, scegli Create clone (Crea clone).

   

3. Durante l'avvio dell'istanza di destinazione, la colonna Status (Stato) del nodo di scrittura visualizza Creating (Creazione) nella colonna Status (Stato). Quando l'istanza è pronta, lo stato diventa Available (Disponibile).

Per preparare il clone per un aggiornamento

1. Il clone è l'istanza "verde" nel modello di implementazione. È l'host del nodo di sottoscrizione della replica. Quando il nodo diventa disponibile, connettiti con psql ed esegui una query sul nuovo nodo di scrittura per ottenere il numero di sequenza del log che identifica l'inizio di un record nel flusso WAL.

   SELECT aurora_volume_logical_start_lsn();

2. Nella risposta alla query, trovi il numero di sequenza del log. Questo numero ti servirà più avanti nel processo, quindi prendine nota.

   postgres=> SELECT aurora_volume_logical_start_lsn();
   aurora_volume_logical_start_lsn 
   ---------------
   0/402E2F0
   (1 row)
   

3. Prima di aggiornare il clone, elimina lo slot di replica del clone.

   SELECT pg_drop_replication_slot('replication_slot_name');

Per aggiornare il cluster a una nuova versione principale

• Dopo aver clonato il nodo provider, utilizza la console Amazon RDS per avviare l'aggiornamento della versione principale sul nodo di sottoscrizione. Evidenzia il nome dell'istanza nella console RDS e seleziona il pulsante Modify (Modifica). Seleziona la versione aggiornata e i gruppi di parametri aggiornati e applica immediatamente le impostazioni per aggiornare l'istanza di destinazione.

  

• È anche possibile utilizzare l'interfaccia della linea di comando per eseguire un aggiornamento:

  aws rds modify-db-cluster —db-cluster-identifier $TARGET_Aurora_ID —engine-version 13.6 —allow-major-version-upgrade —apply-immediately

Per preparare il sottoscrittore (verde)

1. Quando il clone diventa disponibile, connettersi a psql e definire la sottoscrizione. Per farlo, è necessario specificare le seguenti opzioni nel comando CREATE SUBSCRIPTION:

   • subscription_name: il nome della sottoscrizione.

   • admin_user_name: il nome di un utente amministrativo con autorizzazioni rds_superuser.

   • admin_user_password: la password associata all'utente amministrativo.

   • source_instance_URL: l'URL dell'istanza del server di pubblicazione.

   • database: il database a cui si connette il server di sottoscrizione.

   • publication_name: il nome del server di pubblicazione.

   • replication_slot_name: il nome dello slot di replica.

   CREATE SUBSCRIPTION subscription_name 
   CONNECTION 'postgres://admin_user_name:admin_user_password@source_instance_URL/database' PUBLICATION publication_name 
   WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = 'replication_slot_name');

2. Dopo aver creato la sottoscrizione, esegui la query sulla vista pg_replication_origin per recuperare il valore roname, che è l'identificatore dell'origine della replica. Ogni istanza ha un solo roname:

   SELECT * FROM pg_replication_origin;

   Per esempio:

   postgres=> 
   SELECT * FROM pg_replication_origin;
    
   roident | roname 
   ---------+----------
   1 | pg_24586
   

3. Specifica il numero di sequenza del log che hai salvato dalla precedente query del nodo di pubblicazione e il roname restituito dall'[ISTANZA] del nodo di sottoscrizione nel comando. Questo comando utilizza la funzione pg_replication_origin_advance per specificare il punto iniziale nella sequenza del log per la replica.

   SELECT pg_replication_origin_advance('roname', 'log_sequence_number');

   roname è l'identificatore restituito dalla vista pg_replication_origin.

   log_sequence_number è il valore restituito dalla precedente query della funzione aurora_volume_logical_start_lsn.

4. Quindi, utilizza la clausola ALTER SUBSCRIPTION... ENABLE per attivare la replica logica.

   ALTER SUBSCRIPTION subscription_name ENABLE;

5. A questo punto, puoi verificare se la replica funziona. Aggiungi un valore all'istanza di pubblicazione, quindi verifica che il valore sia stato replicato nel nodo di sottoscrizione.

   Quindi, utilizza il comando seguente per monitorare il ritardo di replica sul nodo di pubblicazione:

   SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),
   confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(),
   confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';

   Per esempio:

   postgres=> SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 
   confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';
    
   current_time                   | slot_name             | active | active_pid | diff_size | diff_bytes 
   -------------------------------+-----------------------+--------+------------+-----------+------------
   2022-04-13 15:11:00.243401+00  | replication_slot_name | t      | 21854      | 136 bytes | 136
   (1 row)
   

   È possibile monitorare il ritardo di replica utilizzando i valori diff_size e diff_bytes. Quando questi valori sono pari a 0, la replica ha raggiunto l'istanza database di origine.

Esecuzione di attività successive all'aggiornamento

Al termine dell'aggiornamento, lo stato dell'istanza viene visualizzato come Available (Disponibile) nella colonna Status (Stato) del dashboard della console. Nella nuova istanza, ti consigliamo di effettuare le seguenti operazioni:

• Reindirizza le tue applicazioni in modo che puntino al nodo di scrittura.

• Aggiungi i nodi di lettura per gestire il contenitore e garantire un'elevata disponibilità in caso di problemi con il nodo di scrittura.

• I cluster di database Aurora PostgreSQL richiedono occasionalmente gli aggiornamenti del sistema operativo. Questi aggiornamenti a volte includono una nuova versione della libreria glibc. Durante gli aggiornamenti, ti consigliamo di seguire le linee guida descritte in Regole di confronto supportate in Aurora PostgreSQL.

• Aggiorna le autorizzazioni utente sulla nuova istanza per garantire l'accesso.

Dopo aver testato l'applicazione e i dati sulla nuova istanza, ti consigliamo di eseguire un backup finale dell'istanza iniziale prima di rimuoverla. Per ulteriori informazioni sull'uso della replica logica in un host Aurora, consulta Configurazione della replica logica per il cluster database Aurora PostgreSQL.