Configurazione wal2json

IBM Cloud® Databases for PostgreSQL supporta il plug-in wal2json e consentono la decodifica logica dell'installazione.

Nota:

  • Deprecato: Questo plug-in è deprecato nelle versioni PostgreSQL 9.6 e 10.
  • Supportato: Disponibile solo in PostgreSQL versione 11 e successive.

  1. Per prima cosa, è necessario configurare le impostazioni wal_level, max_replication_slots e max_wal_senders. Cambiare wal_level in logical. I valori max_replication_slots e max_wal_senders devono essere entrambi impostati su un valore superiore a 20. Databases for PostgreSQL riserva 20 slot di replica e mittenti WAL per scopi operativi attuali e futuri.

    curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/configuration
  -H 'Authorization: Bearer <>'
  -H 'Content-Type: application/json'
  -d '{"configuration": {
        "wal_level": "logical",
        "max_replication_slots": 21,
        "max_wal_senders": 21
        }
      }'

  2. Impostare una password per il file repl utente. La password di qualsiasi utente può essere cambiata usando il comando Cloud Databases CLI cdb deployment-user-password o Cloud Databases API /deployments/{id}/users/{username} endpoint. L'utente repl ha i privilegi di REPLICAZIONE e il plug-in wal2json lo utilizza dopo aver impostato una password.

  3. Creare uno slot di replica sul database dall'API Cloud Databases. Inviare una richiesta POST all'endpoint /deployments/{id}/postgresql/logical_replication_slots.

    curl -X POST https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/postgresql/logical_replication_slots   -H 'Authorization: Bearer <>'
  -H 'Content-Type: application/json'
  -d '{"logical_replication_slot": {
       "name": "<slot_name>",
       "database_name": "<database_name>",
       "plugin_type": "wal2json"
       }
     }'

    Il tipo di plug-in deve essere wal2json. Il database deve essere un database esistente. Il nome dello slot può contenere solo lettere minuscole, numeri e il carattere di sottolineatura. È possibile verificare l'esistenza dello slot di replica collegandosi a qualsiasi database ed eseguendo il seguente comando:

    SELECT * FROM pg_replication_slots WHERE slot_name = '<slot_name>';

  4. Per testare il plug-in, eseguire pg_recvlogical dalla riga di comando. Il comando è disponibile con un'installazione di PostgreSQL. Utilizzare l'host e la porta dell'installazione e il nome del database e dello slot creati tramite l'API.

    PGSSLMODE=require pg_recvlogical -d <DATABASE NAME> -U repl -h <HOST> -p <PORT>    --slot <SLOT NAME> --start -o pretty-print=1 -f -

  5. Creare una tabella su ibmclouddb e inserire alcuni dati. Assicurarsi che gli inserimenti vengano effettuati nella riga di comando in esecuzione pg_recvlogical.

    La creazione di tabelle non appare.

wal2json considerazioni e suggerimenti

  • L'impostazione di wal_level a logical aumenta la dimensione dei file WAL perché PostgreSQL ha bisogno di più dati per eseguire la decodifica logica. Se non si usa wal2json, lasciare wal_level al valore predefinito. File WAL più grandi possono richiedere più spazio su disco. Il throughput di scrittura può diminuire, così come il ritardo di replica che influisce sull'alta disponibilità e sulle repliche di sola lettura e i tempi di ripristino più lunghi da un backup.

  • La decodifica logica prevede una serie di restrizioni su ciò che viene replicato. Alcuni di questi includono schema/DDL, sequenze, TRUNCATE e Oggetti di grandi dimensioni.

  • Quando si verifica una commutazione HA controllata, è possibile che gli eventi di replica vengano consegnati più di una volta. Le applicazioni a valle devono essere in grado di gestire gli eventi consegnati più di una volta.

  • Se si crea uno slot di replica logica e un utente non è collegato e non consuma le modifiche, si corre il rischio di esaurire lo spazio su disco della distribuzione. Lo slot di replica indica a PostgreSQL di conservare tutti i registri delle transazioni che contengono le modifiche di cui l'utente ha bisogno. Se non c'è nulla che consuma queste modifiche, PostgreSQL continua a raccoglierle finché non esaurisce lo spazio su disco. È possibile monitorare lo spazio su disco con l'integrazione IBM Cloud® Monitoring. Se si esaurisce lo spazio, è possibile scalare il disco, il che consente di avviare il database. A questo punto, è possibile iniziare a consumare le modifiche o abbandonare lo slot.

  • È possibile verificare la quantità di spazio su disco utilizzata da uno slot di replica specifico e se tale slot di replica ha un consumatore attivo. Utilizzate l'utente admin per eseguire uno dei seguenti comandi:

    PostgreSQL 10.x e più recenti

    SELECT slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) AS lag, active from pg_replication_slots WHERE slot_type='logical';

    PostgreSQL 9.x

    SELECT slot_name, pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(),restart_lsn)) AS lag, active FROM pg_replication_slots WHERE slot_type='logical';

Se si nota un utilizzo del disco superiore al previsto nell'installazione client, è necessario verificare che lo slot di replica abbia un consumatore e non stia esaurendo lo spazio su disco dell'installazione client.