Vous n'êtes pas identifié(e).
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
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
C'est ce que je voulais savoir. Merci.
Hors ligne
Au passage il est à noter que c'est également valide pour un slot de réplication physique.
Julien.
https://rjuju.github.io/
Hors ligne
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
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.
Julien.
https://rjuju.github.io/
Hors ligne
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
( 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.
Julien.
https://rjuju.github.io/
Hors ligne
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
