konfigurieren wal2json

IBM Cloud® Databases for PostgreSQL bereitstellungen unterstützen das wal2json plug-in und ermöglichen so die logische Dekodierung in Ihrem Einsatz.

Hinweis:

  • Veraltet: Dieses Plug-in ist in den Versionen PostgreSQL 9.6 und 10 veraltet.
  • Unterstützt: Nur verfügbar in PostgreSQL Version 11 und höher.
  1. Zunächst müssen Sie die Einstellungen , und wal_level max_replication_slotskonfigurierenmax_wal_senders. Ändern Sie wal_level in logical. Sowohl max_replication_slots als auch max_wal_senders müssen auf einen Wert größer als 20 gesetzt werden. Databases for PostgreSQL reserviert 20 Replikationsslots und WAL-Sender für aktuelle und zukünftige operative Zwecke.

    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. Legen Sie ein Kennwort für den repl-Benutzer fest. Das Kennwort eines Benutzers kann mithilfe des Befehls cdb deployment-user-password des Cloud Databases-CLI-Plug-ins oder mithilfe des Endpunkts /deployments/{id}/users/{username} der Cloud Databases-API geändert werden. Der Benutzer repl verfügt über die Berechtigung für die Replikation und das Plug-in wal2json verwendet diese, nachdem Sie ein Kennwort dafür festgelegt haben.

  3. Erstellen Sie einen Replikations-Slot in der Datenbank über die Cloud Databases-API. Senden Sie eine POST-Anforderung an den Endpunkt /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"
           }
         }'
    

    Der Plug-in-Typ muss wal2json lauten. Die Datenbank muss eine vorhandene Datenbank sein. Der Slotname darf nur Kleinbuchstaben, Zahlen und den Unterstrich enthalten. Sie können das Vorhandensein des Replikations-Slots überprüfen, indem Sie eine Verbindung zu einer beliebigen Datenbank herstellen und den folgenden Befehl ausführen:

    SELECT * FROM pg_replication_slots WHERE slot_name = '<slot_name>';
    
  4. Um das Plug-in zu testen, führen Sie pg_recvlogical über die Befehlszeile aus. Der Befehl ist mit einer Installation von PostgreSQL verfügbar. Verwenden Sie den Host und den Port aus Ihrer Bereitstellung sowie den Namen der Datenbank und des Slots, die Sie über die API erstellt haben.

    PGSSLMODE=require pg_recvlogical -d <DATABASE NAME> -U repl -h <HOST> -p <PORT>    --slot <SLOT NAME> --start -o pretty-print=1 -f -
    
  5. Erstellen Sie eine Tabelle unter ibmclouddb und fügen Sie einige Daten ein. Vergewissern Sie sich, dass die Einfügungen in der Befehlszeile erscheinen, die gerade ausgeführt wird pg_recvlogical.

    Tabellen werden nicht angezeigt.

wal2json überlegungen und Tipps

  • Indem Sie wal_level auf logical setzen, wird die Größe der WAL-Dateien erhöht, da PostgreSQL mehr Daten benötigt, um eine logische Decodierung zu erreichen. Wenn Sie wal2json nicht verwenden, belassen Sie wal_level auf dem Standardwert. Größere WAL-Dateien bedeuten unter Umständen, dass mehr Speicherplatz benötigt wird. Der Schreibdurchsatz kann sich verringern, und es kommt zu Verzögerungen bei der Replikation, die sich auf Hochverfügbarkeits- und Nur-Lese-Replikationen auswirken, sowie zu längeren Wiederherstellungszeiten aus einer Sicherung.

  • Die logische Decodierung bedeutet einige Einschränkungen für bestimmte Replikate. Dazu gehören Schema/DDL, Sequenzen, TRUNCATE und große Objekte.

  • Wenn ein gesteuerter HA-Switchover erfolgt, ist es möglich, dass Replikationsereignisse mehrmals zugestellt werden. Nachgeordnete Anwendungen müssen Ereignisse verarbeiten können, die mehr als einmal zugestellt werden.

  • Wenn Sie einen logischen Replikations-Slot erstellen und ein Konsument nicht verbunden ist und die Änderungen konsumiert, besteht die Gefahr, dass Ihrer Bereitstellung der Plattenspeicher ausgeht. Der Replikations-Slot teilt PostgreSQL mit, dass alle Transaktionsprotokolle mit den Änderungen, die der Konsument benötigt, aufbewahrt werden sollen. Wenn diese Änderungen an keiner Stelle konsumiert werden, werden sie von PostgreSQL weiter gesammelt, bis kein Plattenspeicherplatz mehr verfügbar ist. Sie können den Plattenspeicherplatz mit der IBM Cloud® Monitoring-Integration überwachen. Wenn der Speicherplatz knapp wird, können Sie die Platte skalieren, sodass die Datenbank starten kann. Anschließend können Sie entweder mit dem Konsumieren der Änderungen beginnen oder den Slot löschen.

  • Sie können prüfen, wie viel Plattenspeicherplatz von einem bestimmten Replikationsslot verwendet wird und ob der Replikationsslot über einen aktiven Konsumenten verfügt. Mit dem Benutzer admin können Sie einen der folgenden Befehle ausführen:

    PostgreSQL 10.x und neuer

    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';
    

Wenn Sie bei Ihrer Bereitstellung eine höhere Festplattenauslastung als erwartet feststellen, überprüfen Sie, ob Ihr Replikationsslot über einen Verbraucher verfügt und Ihre Bereitstellung nicht über zu wenig Festplattenplatz verfügt.