Configurer le cluster d'abonnés pour la réplication logique

Sélectionnez une version de la documentation :

Ce document fournit des exemples qui vous montrent comment créer et configurer manuellement un cluster d'abonnés. Un cluster d'abonnés est un cluster de base de données qui reçoit des données répliquées à partir d'un cluster d'éditeur.

Les extraits de code de cette page sont des exemples que vous pouvez utiliser comme modèles, en remplaçant les valeurs par celles de vos ressources AlloyDB Omni.

Avant de commencer

Créer et configurer le cluster d'abonné

  1. Créez un cluster d'abonnés.

    $ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: db-pw-DB_CLUSTER_NAME
type: Opaque
data:
  DB_CLUSTER_NAME: "ENCODED_PASSWORD" # Password is odspassword
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: subscriber
spec:
  databaseVersion: "16.8.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      memory: MEMORY_SIZE
      cpu: CPU_COUNT
      disks:
      - name: DataDisk
        size: DISK_SIZE
EOF

    Remplacez les éléments suivants :

    • DB_CLUSTER_NAME : nom de ce cluster de bases de données, par exemple subscriber-cluster.

    • ENCODED_PASSWORD : mot de passe de connexion à la base de données pour le rôle utilisateur postgres par défaut, encodé sous forme de chaîne base64 (par exemple, Q2hhbmdlTWUxMjM= pour ChangeMe123).

    • CPU_COUNT : nombre de processeurs disponibles pour chaque instance de base de données de ce cluster de bases de données.

    • MEMORY_SIZE : quantité de mémoire par instance de base de données de ce cluster de bases de données. Nous vous recommandons de définir cette valeur sur 8 gigaoctets par processeur. Par exemple, si vous avez défini cpu sur 2 plus haut dans ce fichier manifeste, nous vous recommandons de définir memory sur 16Gi.

    • DISK_SIZE : taille du disque par instance de base de données, par exemple 10Gi.

  2. Recherchez le pod dont vous avez besoin.

    $ kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database, dbs.internal.dbadmin.goog/ha-role=Primary"

  3. Connectez-vous au pod de base de données du cluster d'abonnés.

    $ kubectl get pod
NAME                                          READY   STATUS    RESTARTS   AGE
al-2bce-publisher-0                           3/3     Running   0          20h

$ kubectl exec -ti SUBSCRIBER_POD_NAME  -- /bin/bash
Defaulted container "database" out of: database, logrotate-agent, memoryagent, dbinit (init)
postgres@al-3513-subscriber-0:/$

    Remplacez SUBSCRIBER_POD_NAME par le nom du pod abonné.

  4. Recherchez l'adresse IP de l'équilibreur de charge sur le DBcluster de l'éditeur, comme 10.116.14.190.

    $ kubectl get service
NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)          AGE
al-publisher-rw-ilb      ClusterIP      10.116.14.190   <none>         5432/TCP         21h

  5. Effectuez une sauvegarde du schéma de l'éditeur en tant que copie initiale des données publiées dans la base de données de l'éditeur. La réplication logique ne prend pas en charge la réplication LDD. Un schéma ou une table que vous prévoyez de répliquer doit exister dans la destination (cluster abonné) avant le début de la réplication logique.

    postgres@al-3513-subscriber-0:/$ pg_dump -h PUBLISHER_IP_ADDRESS -U postgres --create --schema-only customer > /tmp/customer.schema-only.sql

    Remplacez PUBLISHER_IP_ADDRESS par l'adresse IP de l'équilibreur de charge sur le cluster de bases de données de l'éditeur.

  6. Appliquez la sauvegarde dans la base de données des abonnés.

    postgres@al-3513-subscriber-0:/$ psql -h localhost -U postgres < /tmp/customer.schema-only.sql

  7. Facultatif : Vérifiez qu'aucune donnée ne figure dans le tableau.

    # There is no data in table company
customer=# select * from company;
id | name | age | salary
----+------+-----+--------
(0 rows)

  8. Créez un abonnement pour la base de données. Assurez-vous que la publication a déjà été créée sur le DBCluster de l'éditeur.

    postgres@al-3513-subscriber-0:/$ CREATE SUBSCRIPTION sub_customer CONNECTION 'host=PUBLISHER_IP_ADDRESS port=5432 user=REPLICATION_USER dbname=DATABASE_NAME password=PUBLISHER_CLUSTER_PASSWORD sslmode=require' PUBLICATION PUBLICATION_NAME WITH (slot_name='REPLICATION_SLOT_NAME');

    Remplacez les éléments suivants :

    • REPLICATION_USER : nom de l'utilisateur qui se connecte à l'emplacement de réplication.
    • DATABASE_NAME : défini sur le nom de la base de données dont vous souhaitez diffuser les modifications à partir de l'emplacement de réplication.
    • PUBLISHER_CLUSTER_PASSWORD : mot de passe de connexion à la base de données pour l'utilisateur postgres du DBCluster de l'éditeur.
    • PUBLICATION_NAME : nom de la publication à laquelle l'abonné s'abonne.
    • REPLICATION_SLOT_NAME : nom de l'emplacement de réplication créé sur le DBCluster de l'éditeur.

  9. Facultatif : Vérifiez la réplication sur le cluster abonné.

    postgres@al-3513-subscriber-0:/$ psql -h localhost -U postgres DATABASE_NAME
customer=# select * from public.company;
id | name  | age | salary
----+-------+-----+--------
  1 | Quinn |  25 |  65000
  2 | Kim   |  22 |  72250
  3 | Bola  |  31 |  53000
  4 | Sasha |  33 | 105000
  5 | Yuri  |  27 |  85000
(5 rows)

  10. Sur le cluster d'éditeurs, ajoutez une ligne au tableau.

    # On the publisher database
$ kubectl exec -ti al-2bce-publisher-0  -- /bin/bash
Defaulted container "database" out of: database, logrotate-agent, memoryagent, dbinit (init)
postgres@al-2bce-publisher-0:/$ psql -h localhost -U postgres DATABASE_NAME
customer=# insert into TABLE_NAME (id, name, age, salary) values (6, 'Alex', 39, 100000);

    Remplacez TABLE_NAME par le nom de la table du DBCluster de l'éditeur à laquelle l'abonné est abonné.

  11. Sur le cluster d'abonné, vérifiez que la ligne ajoutée à la table du cluster d'éditeur a été répliquée dans la table du cluster d'abonné.

    # On the subscriber database, data is synced.
postgres@al-3513-subscriber-0:/$ psql -h localhost -U postgres DATABASE_NAME
customer=# select * from TABLE_NAME;
id | name  | age | salary
----+-------+-----+--------
  1 | Quinn |  25 |  65000
  2 | Kim   |  22 |  72250
  3 | Bola  |  31 |  53000
  4 | Sasha |  33 | 105000
  5 | Yuri  |  27 |  85000
  6 | Alex  |  39 | 100000
(6 rows)

Créer manuellement des tables supplémentaires

Contrairement à replicate_ddl_command dans pglogical, la réplication logique ne synchronise pas automatiquement les modifications LDD. Bien que l'outil Open Source pgl_ddl_deploy offre une solution, vous pouvez également exécuter manuellement des commandes LDD sur l'abonné.

  1. Pour illustrer cela, créez une table nommée finance dans la base de données customer du cluster d'édition.

    # On the publisher database
$ kubectl exec -ti al-2bce-publisher-0  -- /bin/bash
Defaulted container "database" out of: database, logrotate-agent, memoryagent, dbinit (init)
postgres@al-2bce-publisher-0:/$ psql -h localhost -U postgres customer
customer=# create table finance (row text);
CREATE TABLE
customer=# insert into finance values ('critical data');
INSERT 0 1
customer=# ALTER PUBLICATION pub_customer ADD TABLE finance;
ALTER PUBLICATION

  2. Lorsqu'une table est ajoutée au cluster de l'éditeur, vous appliquez manuellement le LDD (création de table) dans l'abonné, puis vous vérifiez la réplication en exécutant la commande suivante sur le cluster de l'abonné.

    postgres@al-3513-subscriber-0:/$ psql -h localhost -U postgres customer
customer=# create table finance (row text);
CREATE TABLE
customer=# ALTER SUBSCRIPTION sub_customer REFRESH PUBLICATION;
ALTER SUBSCRIPTION
customer=# select * from finance;
      row
---------------
critical data
(1 row)

Étapes suivantes