Configuración de wal2json

IBM Cloud® Databases for PostgreSQL admiten el plug-in wal2json plug-in, lo que permite la descodificación lógica en su despliegue.

Nota:

  • Obsoleto: Este complemento está obsoleto en las versiones PostgreSQL 9.6 y 10.
  • Compatible: Sólo disponible en PostgreSQL versiones 11 y superiores.

  1. En primer lugar, debe configurar los valores wal_level, max_replication_slots y max_wal_senders. Cambie wal_level a logical. Tanto max_replication_slots como max_wal_senders deben establecerse en un valor superior a 20. Databases for PostgreSQL reserva 20 ranuras de réplica y remitentes WAL para fines operativos actuales y futuros.

    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. Establezca la contraseña para el usuario repl. La contraseña de cualquier usuario se puede cambiar utilizando el mandato cdb deployment-user-password del plugin de la CLI de Cloud Databases o el punto final /deployments/{id}/users/{username} de la API de Cloud Databases. El usuario repl tiene privilegios de réplica y el plugin wal2json lo utilizará después de que establezca una contraseña para dicho usuario.

  3. Cree una ranura de réplica en la base de datos desde la API de Cloud Databases. Envíe una solicitud POST al punto final /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"
       }
     }'

    El tipo de plugin debe ser wal2json. La base de datos debe ser una base de datos existente. El nombre de la ranura sólo puede contener letras minúsculas, números y el carácter de subrayado. Puede comprobar la existencia de la ranura de replicación conectándose a cualquier base de datos y ejecutando el siguiente comando :

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

  4. Para probar el complemento, ejecute pg_recvlogical desde la comando. El mandato está disponible con una instalación de PostgreSQL. Utilice el host y el puerto de su implantación, y la base de datos y el nombre de la ranura que creó a través de la API.

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

  5. Cree una tabla en ibmclouddb e inserte algunos datos. Asegúrate de que las inserciones salen en la línea de comandos que está ejecutando pg_recvlogical.

    Las creaciones de tablas no aparecen.

wal2json consideraciones y consejos

  • El establecimiento de wal_level en logical aumenta el tamaño de los archivos WAL, ya que PostgreSQL necesita más datos para conseguir la decodificación lógica. Si no utiliza wal2json, deje wal_level por defecto. Archivos WAL más grandes significan potencialmente que se requiere más espacio en disco. El rendimiento de escritura puede disminuir, junto con el retardo de replicación que afecta a la alta disponibilidad y a las réplicas de sólo lectura, y tiempos de restauración más largos a partir de una copia de seguridad.

  • La decodificación lógica tiene un conjunto de restricciones sobre qué se replica. Algunas de ellas son el esquema/DDL, secuencias, TRUNCATE y objetos grandes.

  • Cuando se produce una conmutación de HA controlada, es posible que los sucesos de réplica se entreguen más de una vez. Las aplicaciones en sentido descendente deben poder manejar sucesos que se entreguen más de una vez.

  • Si crea una ranura de réplica lógica y no hay un consumidor que esté conectado y consumiendo los cambios, corre el riesgo de que el despliegue agote el espacio de disco. La ranura de réplica indica a PostgreSQL que conserve todos los registros de transacciones que tengan los cambios que necesita el consumidor. Si no hay nada que consuma estos cambios, PostgreSQL seguirá recopilándolos hasta que se agote el espacio de disco. Puede supervisar el espacio de disco con la integración de IBM Cloud® Monitoring. Si se queda sin espacio, puede escalar el disco, lo cual permite que se inicie la base de datos. A continuación, puede empezar a consumir los cambios o descartar la ranura.

  • Puede comprobar cuánto espacio de disco está utilizando una ranura de réplica específica y si dicha ranura de réplica tiene o no un consumidor activo. Utilice el usuario admin para ejecutar uno de los mandatos siguientes:

    PostgreSQL 10.x y posterior

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

Si observa un uso de disco superior al esperado en su implantación, solucione el problema comprobando que su ranura de replicación tiene un consumidor y no está agotando el espacio de disco de su implantación.