Configurazione della replica SQL logica Postgre con cluster DB Multi-AZ per Amazon RDS

Utilizzando la replica SQL logica di Postgre con il cluster DB Multi-AZ, è possibile replicare e sincronizzare singole tabelle anziché l'intera istanza del database. La replica logica utilizza un modello di pubblicazione e sottoscrizione per replicare le modifiche da un'origine in uno o più destinatari. Funziona utilizzando i record delle modifiche del log () di Postgre write-ahead. SQL WAL Per ulteriori informazioni, consulta Esecuzione della replica logica per Amazon RDS for Postgre SQL.

Quando crei un nuovo slot di replica logica sull'istanza database di scrittura di un cluster database multi-AZ, lo slot viene copiato in modo asincrono su ogni istanza database di lettura nel cluster. Gli slot delle istanze database di lettura vengono continuamente sincronizzati con quelli dell'istanza database di scrittura.

La replica logica è supportata per i cluster DB Multi-AZ in esecuzione RDS per Postgre SQL versione 14.8-R2 e successive e 15.3-R2 e successive.

Nota

Oltre alla funzionalità di replica SQL logica nativa di Postgre, anche i cluster DB Multi-AZ in esecuzione per Postgre supportano l'estensione. RDS SQL pglogical

Per ulteriori informazioni sulla replica SQL logica di Postgre, consulta Replica logica nella documentazione di Postgre. SQL

Prerequisiti

Per configurare la replica SQL logica Postgre per i cluster DB Multi-AZ, è necessario soddisfare i seguenti prerequisiti.

• L'account utente deve essere membro del gruppo rds_superuser e disporre dei privilegi rds_superuser. Per ulteriori informazioni, consulta Comprendere i SQL ruoli e le autorizzazioni di Postgree.

• Il cluster database multi-AZ deve essere associato a un gruppo di parametri del cluster database personalizzato in modo da poter configurare i valori dei parametri descritti nella procedura seguente. Per ulteriori informazioni, consulta Utilizzo di gruppi di parametri cluster di database per cluster database Multi-AZ.

Configurazione della replica logica

Per configurare la replica logica per un cluster database multi-AZ, devi abilitare parametri specifici all'interno del gruppo di parametri del cluster database associato, quindi creare slot di replica logica.

Nota

A partire dalla SQL versione 16 di Postgre, è possibile utilizzare le istanze Reader DB del cluster DB Multi-AZ per la replica logica.

Per configurare la replica logica per un cluster DB Multi-AZ di Postgre RDS SQL

1. Apri il gruppo di parametri del cluster DB personalizzato associato al tuo cluster DB RDS for SQL Postgre Multi-AZ.

2. Nel campo di ricerca Parametri, individua il parametro statico rds.logical_replication e imposta il relativo valore su 1. Questa modifica dei parametri può aumentare la WAL generazione, quindi abilitala solo quando utilizzi slot logici.

3. Nell'ambito di questa modifica, configura i seguenti parametri del cluster database.

   • max_wal_senders

   • max_replication_slots

   • max_connections

   A secondo dell'utilizzo previsto, potrebbe anche essere necessario modificare i valori dei seguenti parametri. Tuttavia, in molti casi, i valori predefiniti sono sufficienti.

   • max_logical_replication_workers

   • max_sync_workers_per_subscription

4. Riavvia il cluster database multi-AZ per rendere effettivi i valori dei parametri. Per istruzioni, consulta Riavvio di un cluster DB Multi-AZ e di istanze DB di lettura per Amazon RDS.

5. Crea uno slot di replica logica sull'istanza database di scrittura del cluster database multi-AZ come illustrato in Lavorare con gli slot di replica logica. Questo processo richiede che venga specificato un plug-in di decodifica. Attualmente, RDS per Postgre SQL supporta i pgoutput plugin test_decodingwal2json, e forniti con Postgre. SQL

   Lo slot viene copiato in modo asincrono su ogni istanza database di lettura nel cluster.

6. Verifica lo stato dello slot su tutte le istanze database di lettura del cluster database multi-AZ. A tale scopo, verifica la vista pg_replication_slots su tutte le istanze database di lettura e assicurati che lo stato confirmed_flush_lsn stia progredendo mentre l'applicazione sta utilizzando attivamente le modifiche logiche.

   I seguenti comandi mostrano come controllare lo stato di replica sulle istanze database di lettura.

   % psql -h test-postgres-instance-2.abcdefabcdef.us-west-2.rds.amazonaws.com
   
   postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
     slot_name   | slot_type | confirmed_flush_lsn
   --------------+-----------+---------------------
    logical_slot | logical   | 32/D0001700
   (1 row)
   
   postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
     slot_name   | slot_type | confirmed_flush_lsn
   --------------+-----------+---------------------
    logical_slot | logical   | 32/D8003628
   (1 row)
   
   % psql -h test-postgres-instance-3.abcdefabcdef.us-west-2.rds.amazonaws.com
   
   postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
     slot_name   | slot_type | confirmed_flush_lsn
   --------------+-----------+---------------------
    logical_slot | logical   | 32/D0001700
   (1 row)
   
   postgres=> select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
     slot_name   | slot_type | confirmed_flush_lsn
   --------------+-----------+---------------------
    logical_slot | logical   | 32/D8003628
   (1 row)

Dopo aver completato le attività di replica, interrompi il processo di replica, elimina gli slot di replica e disattiva la replica logica. Per disattivare la replica logica, modifica il gruppo di parametri del cluster database e reimposta il valore di rds.logical_replication su 0. Riavvia il cluster database per applicare la modifica apportata al parametro.

Limitazioni e consigli

Le seguenti limitazioni e raccomandazioni si applicano all'utilizzo della replica logica con cluster DB Multi-AZ che eseguono Postgre versione 16: SQL

• È possibile utilizzare solo istanze Writer DB per creare o eliminare slot di replica logica. Ad esempio, il CREATE SUBSCRIPTION comando deve utilizzare l'endpoint cluster writer nella stringa di connessione host.

• È necessario utilizzare l'endpoint cluster writer durante qualsiasi sincronizzazione o risincronizzazione delle tabelle. Ad esempio, è possibile utilizzare i seguenti comandi per risincronizzare una tabella appena aggiunta:

  Postgres=>ALTER SUBSCRIPTION subscription-name CONNECTION host=writer-endpoint
  Postgres=>ALTER SUBSCRIPTION subscription-name REFRESH PUBLICATION

• È necessario attendere il completamento della sincronizzazione della tabella prima di utilizzare le istanze DB del lettore per la replica logica. È possibile utilizzare la tabella del pg_subscription_rel catalogo per monitorare la sincronizzazione delle tabelle. La sincronizzazione della tabella è completa quando la srsubstate colonna è impostata su ready ()r.

• Si consiglia di utilizzare gli endpoint dell'istanza per la connessione di replica logica una volta completata la sincronizzazione iniziale della tabella. Il comando seguente riduce il carico sull'istanza DB di Writer affidando la replica a una delle istanze DB Reader:

  Postgres=>ALTER SUBSCRIPTION subscription-name CONNECTION host=reader-instance-endpoint

  Non è possibile utilizzare lo stesso slot su più di un'istanza DB alla volta. Quando due o più applicazioni replicano le modifiche logiche da diverse istanze DB del cluster, alcune modifiche potrebbero andare perse a causa di un failover del cluster o di un problema di rete. In queste situazioni, è possibile utilizzare gli endpoint dell'istanza per la replica logica nella stringa di connessione host. L'altra applicazione che utilizza la stessa configurazione mostrerà il seguente messaggio di errore:

  replication slot slot_name is already active for PID x providing immediate feedback.

• Durante l'utilizzo dell'pglogicalestensione, è possibile utilizzare solo l'endpoint cluster writer. L'estensione presenta limitazioni note che possono creare slot di replica logica inutilizzati durante la sincronizzazione delle tabelle. Gli slot di replica obsoleti riservano i file write-ahead log (WAL) e possono causare problemi di spazio su disco.