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
- Installez Omni Operator sur Kubernetes.
- Assurez-vous de créer un emplacement de réplication, un cluster d'éditeurs et une publication. Pour en savoir plus, consultez Créer des emplacements de réplication et des publications.
Créer et configurer le cluster d'abonnés
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: "15.7.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 utilisateurpostgres
par défaut, encodé en tant que chaîne base64 (par exemple,Q2hhbmdlTWUxMjM=
pourChangeMe123
).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 Go par processeur. Par exemple, si vous avez définicpu
sur2
plus tôt dans ce fichier manifeste, nous vous recommandons de définirmemory
sur16Gi
.DISK_SIZE
: taille de disque par instance de base de données (par exemple,10Gi
).
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"
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 de l'abonné.Recherchez l'adresse IP de l'équilibreur de charge sur le DBcluster de l'éditeur, par exemple
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
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 n'est pas compatible avec la réplication DDL. 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 DBcluster de l'éditeur.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
(Facultatif) Vérifiez qu'aucune donnée n'est présente dans le tableau.
# There is no data in table company customer=# select * from company; id | name | age | salary ----+------+-----+-------- (0 rows)
Créez un abonnement pour la base de données. Assurez-vous que la publication est déjà 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
de DBCluster de l'éditeur. - PUBLICATION_NAME: nom de la publication à laquelle l'abonné est abonné.
- REPLICATION_SLOT_NAME: nom de l'emplacement de réplication créé sur le DBCluster de l'éditeur.
Facultatif: Vérifiez la réplication sur le cluster d'abonnés.
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)
Dans le cluster des é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 dans le DBCluster de l'éditeur auquel l'abonné est abonné.
Sur le cluster abonné, vérifiez que la ligne ajoutée à la table dans le cluster éditeur a été répliquée dans la table du cluster 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
La réplication logique ne synchronise pas automatiquement les modifications DDL, contrairement à replicate_ddl_command
dans pglogical
. Bien que l'outil Open Source pgl_ddl_deploy
propose une solution, vous pouvez également exécuter manuellement des commandes DDL sur l'abonné.
Pour illustrer cela, créez une table appelée
finance
dans la base de donnéescustomer
du cluster de l'éditeur.# 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
Lorsqu'une table est ajoutée au cluster de l'éditeur, vous appliquez manuellement le DDL (création de table) dans l'abonné, puis vérifiez la réplication en exécutant ce qui suit 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)