PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 25/06/2021 11:39:59

Réplication logique et perte de connexion temporaire

Bonjour,

J'aimerais savoir ce qui se passe dans le cadre d'une réplication logique si l'hôte cible est temporairement injoignable.

Les ordres logiques sont conservés et transmis lorsque la connexion est à nouveau effective, ou bien ils sont perdus ?

Hors ligne

#2 25/06/2021 12:15:46

ioguix
Administrateur

Re : Réplication logique et perte de connexion temporaire

Bonjour,

La réplication logique repose sur un slot de réplication, situé coté source (publisher) et qui permet d'y conserver les WAL tant qu'ils n'ont pas été décodés et envoyés vers la cible (subscriber) associée.


Donc, si le subscriber se déconnecte, le slot impose au publisher de conserver les WAL jusqu'au retour du subscriber afin qu'il rattrape son retard.


L'absence prolongée d'un subscriber induit donc un risque sur le publisher en cas de saturation de l'espace disque à cause de la rétention des WALs.

Hors ligne

#3 25/06/2021 12:18:27

Re : Réplication logique et perte de connexion temporaire

C'est ce que je voulais savoir. Merci.

Hors ligne

#4 25/06/2021 13:13:10

rjuju
Administrateur

Re : Réplication logique et perte de connexion temporaire

Au passage il est à noter que c'est également valide pour un slot de réplication physique.

Hors ligne

#5 25/06/2021 14:41:33

ruizsebastien
Membre

Re : Réplication logique et perte de connexion temporaire

rjuju a écrit :

Au passage il est à noter que c'est également valide pour un slot de réplication physique.

que si la replication est synchrone (mais je me trompe peut être)


Cordialement,

Sébastien.

Hors ligne

#6 26/06/2021 05:04:05

rjuju
Administrateur

Re : Réplication logique et perte de connexion temporaire

ruizsebastien a écrit :
rjuju a écrit :

Au passage il est à noter que c'est également valide pour un slot de réplication physique.

que si la replication est synchrone (mais je me trompe peut être)

Non, c'est pareil en asynchrone.  Le but d'un slot de réplication est de garantir l'accès aux informations nécessaires pour un serveur secondaire.  Dans le cas de la réplication physique c'est uniquement les WAL, pour la réplication logique cela inclue également un plugin ainsi que des informations concernant le catalogue afin de pouvoir décoder les changements.


Mais dans les 2 cas, synchrone ou pas, les WAL seront conservés aussi longtemps que nécessaire, à moins d'utiliser le max_slot_wal_keep_size introduit dans postgres 13.

Hors ligne

#7 08/07/2021 10:59:35

Re : Réplication logique et perte de connexion temporaire

Bonjour,

Mettre les noeuds d'un cluster Patroni en WAL_LEVEL=LOGICAL afin de créer des publications vers un serveur à l'extérieur du cluster ; d'un point de vue théorique, ça ne devrait pas poser de problème n'est-ce pas ?
( bon ; en fait j'ai pété mon cluster ; il ne redémarre pas, j'essaye de comprendre pourquoi...)

Dernière modification par herve.lefebvre (08/07/2021 11:41:24)

Hors ligne

#8 08/07/2021 19:43:44

rjuju
Administrateur

Re : Réplication logique et perte de connexion temporaire

herve.lefebvre a écrit :

( bon ; en fait j'ai pété mon cluster ; il ne redémarre pas, j'essaye de comprendre pourquoi...)

Les logs des différents serveurs devraient vous donner des explications.

Hors ligne

#9 10/07/2021 14:53:32

Re : Réplication logique et perte de connexion temporaire

Hello,

J'ai fini par résoudre le problème qui n'était que consécutif à deux bêtises de ma part. Je les relate ici, ça pourra toujours servir à quelqu'un d'autre :

1) J'avais créé un tablespace dans '/usr/local/migration/tablespaces/' et d'autres dans des sous-répertoires '/usr/local/migration/tablespaces/xxx/' ; ce qui fait planter pg_basebackup (il a besoin de répertoires vides quand il démarre le backup pour créer le noeud esclave).

2) J'ai fait une faute de frappe en définissant une clef/valeur sur la configuration dynamique (donc pas de trace dans les fichiers de conf statiques). J'avais mis "checkpoint: dast" au lieu de "checkpoint: fast". J'ai vu ça en regardant dans le fichier de conf patroni JSON créé dynamiquement  dans $PGDATA.

Bref, juste des trucs de ma faute.

Hors ligne

Pied de page des forums