Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Dans le cadre d'une réplication logique, j'ai fait un dump d'une base sans les donnéesd 'un serveur primaire (-s) et restauré la sauvegarde sur un serveur secondaire.
Puis j'ai configuré le primaire ainsi :
wal_level = logical # minimal, replica, or logical
# (change requires restart)
#fsync = on # flush data to disk for crash safety
# (turning this off can cause
# unrecoverable data corruption)
#synchronous_commit = on # synchronization level;
# off, local, remote_write, remote_apply, or on
...
#synchronous_standby_names = ''
J'ai crée la publication :
CREATE PUBLICATION f132880_publication
FOR ALL TABLES
WITH (publish = 'insert, update, delete, truncate', publish_via_partition_root = false);
Puis créé la souscription sur le serveur distant :
CREATE SUBSCRIPTION subscription_f132880
CONNECTION 'host=xxx user port=5432 user=xxx dbname=F132880'
PUBLICATION f132880_publication
WITH (connect = true, enabled = true, create_slot = false, slot_name = subscription_f132880, synchronous_commit = 'off');
A la suite de quoi, les données ont bien été copiées sur le serveur secondaire depuis le primaire, et les commandes DDL sur ce dernier reproduites sur le secondaire.
Par la suite, une nouvelle table a été créée sur le primaire. Conformément à la doc, j'ai créé la même table sur le serveur secondaire, les commandes DML étant ignorées
Mais :
* la nouvelle table ne s'est pas rempli automatiquement des valeurs de la table présente sur le primaire.
* tout ajout dans la nouvelle table primaire ne s'ajoute pas à la table identique secondaire.
A l'évidence quelque chose m'a échappé, mais je ne trouve pas quoi.
Merci d'avance pour votre aide
Hors ligne
Je pense qu'il faudrait un exemple complet parce que, comme on dit, "pour moi, ça marche"
Notamment, êtes-vous sûr d'avoir créé la nouvelle table dans la base publiée ?
Guillaume.
Hors ligne
Notamment, êtes-vous sûr d'avoir créé la nouvelle table dans la base publiée ?
absolument : j'ai les deux sous les yeux dans pgadmin4. J'ai même rempli la seconde table avec les données de la première en me disant qu'il fallait peut-être initier le truc (j'y croyais pas vraiment).
Je pense qu'il faudrait un exemple complet
un exemple de ? sous quelle forme ?
Hors ligne
bonjour,
Cette nouvelle table possède t'elle une clef primaire ?
Cordialement,
Sébastien.
Hors ligne
les deux tables ont exactement la même définition : j'ai repris le script de la première pour créer la seconde ainsi que la sequence.
Hors ligne
Un exemple sous la forme d'un script SQL : création de la publication, création de la souscription, insertion dans la table déjà présente, vérificiation que les donnes sont bien dans la table de la deuxième base, ajout d'une nouvelle table dans les deux bases, ajout de données dans la nouvelle table du serveur 1, vérification (échouée d'après vous) que les données arrivent sur la table du deuxième serveur.
Guillaume.
Hors ligne
et donc quid de la PK ?
on peut avoir le DDL de cette nouvelle table ?
Cordialement,
Sébastien.
Hors ligne
Pour donner un exemple de ce que j'entends comme script complet, en voici un :
\set ECHO all
\c postgres
DROP DATABASE b1;
CREATE DATABASE b1;
DROP DATABASE b2;
CREATE DATABASE b2;
\c b1
CREATE TABLE t1(id integer);
INSERT INTO t1 VALUES (1);
SELECT pg_create_logical_replication_slot('slot_pub1', 'pgoutput');
CREATE PUBLICATION pub1 FOR ALL TABLES;
\c b2
CREATE TABLE t1(id integer);
CREATE SUBSCRIPTION sub1 CONNECTION 'dbname=b1' PUBLICATION pub1
WITH (create_slot = false, slot_name = 'slot_pub1');
SELECT pg_sleep(10);
SELECT * FROM t1;
\c b1
CREATE TABLE t2(id integer);
INSERT INTO t2 VALUES (2);
\c b2
CREATE TABLE t2(id integer);
ALTER SUBSCRIPTION sub1 REFRESH PUBLICATION;
SELECT pg_sleep(10);
SELECT * FROM t2;
Et comme vous n'avez pas parlé d'un ALTER SUBSCRIPTION REFRESH PUBLICATION, je suppose que c'est ce que vous avez oublié.
Guillaume.
Hors ligne
J'utilise pgAdmin4 pour tester l'ajout et la suppression de de données.
La publication sur le serveur primaire :
CREATE PUBLICATION f132880_publication
FOR ALL TABLES
WITH (publish = 'insert, update, delete, truncate', publish_via_partition_root = false);
La souscription sur le serveur secondaire :
CREATE SUBSCRIPTION subscription_f132880
CONNECTION 'host=xxx user port=5432 user=xxx dbname=F132880'
PUBLICATION f132880_publication
WITH (connect = true, enabled = true, create_slot = false, slot_name = subscription_f132880, synchronous_commit = 'off');
Jusque là tout fonctionne.
Définition de la table créée ultérieurement sur le primaire et recréée sur le secondaire :
CREATE TABLE IF NOT EXISTS public.f132880_ensemble
(
ogc_fid integer NOT NULL DEFAULT nextval('f132880_ensemble_ogc_fid_seq'::regclass),
id character varying(254) COLLATE pg_catalog."default",
x numeric(24,15),
y numeric(24,15),
z numeric(24,15),
code character varying(254) COLLATE pg_catalog."default",
geometrie character varying(254) COLLATE pg_catalog."default",
type character varying(254) COLLATE pg_catalog."default",
interpret character varying(254) COLLATE pg_catalog."default",
numens numeric(10,0),
date date,
geom geometry(MultiPolygon,2154),
CONSTRAINT f32880_ensemble_pkey PRIMARY KEY (ogc_fid1)
La séquence pour la clef primaire :
CREATE SEQUENCE public.f132880_ensemble_ogc_fid_seq
INCREMENT 1
START 1
MINVALUE 1
MAXVALUE 2147483647
CACHE 1;
ALTER SEQUENCE public.f132880_ensemble_ogc_fid_seq
OWNER TO blois;
Les modifications sur les tables initiales fonctionnaient toujours mais la table secondaire f132880_ensemble était vide.
Effectivement, je n'avais pas exécuté de
ALTER SUBSCRIPTION
Donc j'ai rectifié le tir sur le serveur secondaire:
alter subscription subscription_f132880 REFRESH publication ;
Même après cela, la table sur le secondaire reste vide mais tout fonctionne toujours pour les autres.
JE ne vois rien de particulier dans les logs du secondaire, mais j'y retourne ce matin plus avant.
Hors ligne
j'ai trouvé avec la fin du log d'hier :
Après la création de la table sur le secondaire et la commande
ALTER SUBSCRIPTION
, j'ai omis d'attribuer les droits de SELECT au rôle crée pour la réplication.
Une fois GRANT SELECT ON TABLE f132800_ensemble to replicant, la table sur le secondair s'est correctement remplie.
Merci pour l'attention.
Hors ligne
Pages : 1