Configuration de wal2json

IBM Cloud® Databases for PostgreSQL prennent en charge le plug-in wal2json ce qui permet le décodage logique sur votre déploiement.

Remarque :

  • Déclassé : Ce plug-in est obsolète dans les versions PostgreSQL 9.6 et 10.
  • Pris en charge : Uniquement disponible dans les versions 11 et supérieures de PostgreSQL.

  1. Tout d'abord, vous devez configurer les paramètres wal_level, max_replication_slots et max_wal_senders. Remplacez la valeur de wal_level par logical. Les valeurs max_replication_slotset max_wal_senders doivent être définies sur une valeur supérieure à 20. Databases for PostgreSQL réserve 20 emplacements de réplication et expéditeurs WAL à des fins opérationnelles courantes et futures.

    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. Définissez un mot de passe pour l'utilisateur repl. Le mot de passe de tout utilisateur peut être modifié à l'aide de la commande cdb deployment-user-password du plug-in d'interface de ligne de commande Cloud Databases ou du noeud final /deployments/{id}/users/{username} de l'API Cloud Databases. L'utilisateur repl dispose des privilèges REPLICATION et le plug-in wal2json l'utilise une fois que vous avez défini un mot de passe.

  3. Créez un emplacement de réplication sur la base de données à partir de l'API Cloud Databases. Envoyez une demande POST au noeud 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"
       }
     }'

    Le type de plug-in doit être wal2json. La base de données doit être une base de données existante. Le nom du slot ne peut contenir que des lettres minuscules, des chiffres et le caractère de soulignement. Vous pouvez vérifier l'existence du slot de réplication en vous connectant à n'importe quelle base de données et en exécutant la commande suivante :

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

  4. Pour tester le plug-in, lancez pg_recvlogical à partir de la ligne de commande. La commande est disponible avec une installation de PostgreSQL. Utilisez l'hôte et le port de votre déploiement, ainsi que la base de données et le nom du slot que vous avez créés via 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. Créez une table sur ibmclouddb et insérez des données. Veillez à ce que les insertions apparaissent dans la ligne de commande qui s'exécute pg_recvlogical.

    Les créations de tableaux n'apparaissent pas.

wal2json considérations et conseils

  • L'affectation de la valeur wal_level au paramètre logical a pour conséquence d'augmenter la taille des fichiers WAL car PostgreSQL a besoin de plus de données pour réaliser le décodage logique. Si vous n'utilisez pas wal2json, laissez la valeur par défaut de wal_level. Des fichiers WAL plus volumineux peuvent nécessiter plus d'espace disque. Le débit d'écriture peut diminuer, tout comme le décalage de la réplication qui affecte la haute disponibilité et les répliques en lecture seule, ainsi que des temps de restauration plus longs à partir d'une sauvegarde.

  • Le décodage logique comporte un ensemble de restrictions sur ce qu'il convient de répliquer. Parmi ces restrictions, citons le schéma/DDL, les séquences, TRUNCATE et les objets LOB.

  • Lorsqu'un basculement à haute disponibilité contrôlé se produit, il est possible que les événements de réplication soient livrés plusieurs fois. Les applications en aval doivent être en mesure de gérer les événements distribués plusieurs fois.

  • Si vous créez un emplacement de réplication logique et qu'un consommateur n'est pas connecté et ne consomme pas les modifications, vous pouvez courez le risque de manquer d'espace disque pour votre déploiement. L'emplacement de réplication indique à PostgreSQL qu'il doit conserver tous les journaux de transactions comportant les modifications dont le consommateur a besoin. Si ces modifications ne sont pas consommées, PostgreSQL continue de les collecter jusqu'à ce qu'il ne dispose plus de suffisamment d'espace disque. Vous pouvez surveiller l'espace disque avec l'intégration IBM Cloud® Monitoring . Si vous manquez d'espace, vous pouvez augmenter la capacité du disque et permettre ainsi le démarrage de la base de données. Vous pouvez ensuite commencer à consommer les modifications ou supprimer l'emplacement.

  • Vous pouvez vérifier la quantité d'espace disque utilisée par un emplacement de réplication spécifique et déterminer si cet emplacement de réplication a un consommateur actif. Utilisez l'utilisateur admin pour exécuter l'une des commandes suivantes :

    PostgreSQL 10.x et version plus récente

    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 vous constatez une utilisation du disque plus importante que prévu sur votre déploiement, dépannez en vérifiant que votre slot de réplication dispose d'un consommateur et que votre déploiement n'est pas à court d'espace disque.