Share via

Decodifica logica

  • Articolo

SI APPLICA A: Database di Azure per PostgreSQL - Server singolo

Importante

Database di Azure per PostgreSQL - Server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per PostgreSQL - Server flessibile. Per altre informazioni sulla migrazione a Database di Azure per PostgreSQL - Server flessibile, vedere What's happening to Database di Azure per PostgreSQL Single Server?.

La decodifica logica in PostgreSQL consente di trasmettere le modifiche ai dati ai consumer esterni. La decodifica logica viene usata comunemente per gli scenari di streaming di eventi e change data capture.

La decodifica logica usa un plug-in di output per convertire il log write-ahead di Postgres in un formato leggibile. Database di Azure per PostgreSQL fornisce i plug-in di output wal2json, test_decoding e pgoutput. Pgoutput è reso disponibile da PostgreSQL da PostgreSQL versione 10 e successive.

Per una panoramica del funzionamento della decodifica logica di Postgres, visitare il blog.

Nota

La replica logica con pubblicazione/sottoscrizione PostgreSQL non è supportata con Database di Azure per PostgreSQL - Server singolo.

Configurare il server

La decodifica logica e le repliche in lettura dipendono dal log write ahead (WAL) di Postgres per informazioni. Queste due funzionalità richiedono livelli diversi di registrazione da Postgres. La decodifica logica richiede un livello superiore di registrazione rispetto alle repliche in lettura.

Per configurare il livello corretto di registrazione, usare il parametro di supporto della replica di Azure. Il supporto della replica di Azure include tre opzioni di impostazione:

  • Off : inserisce le informazioni meno contenute nel wal. Questa impostazione non è disponibile nella maggior parte dei server Database di Azure per PostgreSQL.
  • Replica : più dettagliato di Off. Si tratta del livello minimo di registrazione necessario per il funzionamento delle repliche in lettura. Questa impostazione è l'impostazione predefinita nella maggior parte dei server.
  • Logico : più dettagliato rispetto a Replica. Si tratta del livello minimo di registrazione per il funzionamento della decodifica logica. Le repliche di lettura funzionano anche in questa impostazione.

Utilizzare l'interfaccia della riga di comando di Azure

  1. Impostare azure.replication_support su logical.

    az postgres server configuration set --resource-group mygroup --server-name myserver --name azure.replication_support --value logical

  2. Riavviare il server per applicare la modifica.

    az postgres server restart --resource-group mygroup --name myserver

  3. Se si esegue Postgres 9.5 o 9.6 e si usa l'accesso alla rete pubblica, aggiungere la regola del firewall per includere l'indirizzo IP pubblico del client da cui verrà eseguita la replica logica. Il nome della regola del firewall deve includere _replrule. Ad esempio, test_replrule. Per creare una nuova regola del firewall sul server, eseguire il comando az postgres server firewall-rule create.

Con il portale di Azure

  1. Impostare il supporto della replica di Azure su logico. Seleziona Salva.

    Database di Azure per PostgreSQL - Replica - Supporto della replica di Azure

  2. Riavviare il server per applicare la modifica selezionando Sì.

    Database di Azure per PostgreSQL - Replica - Confermare il riavvio

  3. Se si esegue Postgres 9.5 o 9.6 e si usa l'accesso alla rete pubblica, aggiungere la regola del firewall per includere l'indirizzo IP pubblico del client da cui verrà eseguita la replica logica. Il nome della regola del firewall deve includere _replrule. Ad esempio, test_replrule. Quindi selezionare Salva.

    Database di Azure per PostgreSQL - Replica - Aggiungere una regola del firewall

Avviare la decodifica logica

La decodifica logica può essere utilizzata tramite il protocollo di streaming o l'interfaccia SQL. Entrambi i metodi usano gli slot di replica. Uno slot rappresenta un flusso di modifiche da un singolo database.

L'uso di uno slot di replica richiede i privilegi di replica di Postgres. Al momento, il privilegio di replica è disponibile solo per l'utente amministratore del server.

Protocollo di streaming

L'utilizzo delle modifiche tramite il protocollo di streaming è spesso preferibile. È possibile creare un consumer o un connettore personalizzato oppure usare uno strumento come Debezium.

Per un esempio sull'uso del protocollo di streaming con pg_recvlogical, vedere la documentazione di wal2json.

Interfaccia SQL

Nell'esempio seguente viene usata l'interfaccia SQL con il plug-in wal2json.

  1. Creare uno slot.

    SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');

  2. Eseguire comandi SQL. Ad esempio:

    CREATE TABLE a_table (
   id varchar(40) NOT NULL,
   item varchar(40),
   PRIMARY KEY (id)
);

INSERT INTO a_table (id, item) VALUES ('id1', 'item1');
DELETE FROM a_table WHERE id='id1';

  3. Utilizzare le modifiche.

    SELECT data FROM pg_logical_slot_get_changes('test_slot', NULL, NULL, 'pretty-print', '1');

    L'output sarà simile al seguente:

    {
      "change": [
      ]
}
{
      "change": [
               {
                        "kind": "insert",
                        "schema": "public",
                        "table": "a_table",
                        "columnnames": ["id", "item"],
                        "columntypes": ["character varying(40)", "character varying(40)"],
                        "columnvalues": ["id1", "item1"]
               }
      ]
}
{
      "change": [
               {
                        "kind": "delete",
                        "schema": "public",
                        "table": "a_table",
                        "oldkeys": {
                              "keynames": ["id"],
                              "keytypes": ["character varying(40)"],
                              "keyvalues": ["id1"]
                        }
               }
      ]
}

  4. Eliminare lo slot dopo averlo usato.

    SELECT pg_drop_replication_slot('test_slot');

Slot di monitoraggio

È necessario monitorare la decodifica logica. Qualsiasi slot di replica inutilizzato deve essere eliminato. Gli slot sono in attesa nei log WAL postgres e nei cataloghi di sistema pertinenti fino a quando le modifiche non vengono lette da un consumer. Se il consumer non riesce o non è stato configurato correttamente, i log non utilizzati si accumulano e riempiono lo spazio di archiviazione. Inoltre, i log non utilizzati aumentano il rischio di wrapping dell'ID transazione. Entrambe le situazioni possono causare la mancata disponibilità del server. Pertanto, è fondamentale che gli slot di replica logica vengano utilizzati continuamente. Se uno slot di replica logica non viene più usato, eliminarlo immediatamente.

La colonna "attiva" nella visualizzazione pg_replication_slots indicherà se è presente un consumer connesso a uno slot.

SELECT * FROM pg_replication_slots;

Impostare avvisi sulle Archiviazione usate e Il ritardo massimo tra le metriche delle repliche per notificare quando i valori aumentano oltre le soglie normali.

Importante

È necessario eliminare gli slot di replica inutilizzati. La mancata esecuzione di questa operazione può causare l'indisponibilità del server.

Come eliminare uno slot

Se non si utilizza attivamente uno slot di replica, è consigliabile eliminarlo.

Per eliminare uno slot di replica denominato test_slot tramite SQL:

SELECT pg_drop_replication_slot('test_slot');

Importante

Se si smette di usare la decodifica logica, modificare azure.replication_support tornare a replica o off. I dettagli WAL conservati da logical sono più verbosi e devono essere disabilitati quando la decodifica logica non è in uso.

Passaggi successivi