Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai pour la première fois eu à créé une réplication logique entre un schéma de ma BDD et un serveur client.
Tout se passait bien jusqu’à ce que je me rende compte que lors de transactions longues sur d'autres schémas (je dois traiter de grosses volumétries) les fichiers dans "pg_replslot" s'accumulaient jusqu’à saturation du disque en attente de la fin de la transaction et du commit.
Ce comportement est-il normal ? Est-il possible d’éviter que la réplication ne remplisse le disque en attente de commit ou de fichier ne concernant pas directement la réplication ?
N'hésitez pas à me demandé plus de détails si je ne suis pas clair (désolé je ne suis pas DBA).
Par avance merci,
Hors ligne
Bonjour,
Tu as du mettre un paramètre qui exige le commit avant l'envoi du journal.
Peut-être as tu créé un slot de replication qui n'est jamais demandé par un esclave, dans l'attente postgres conserve les wal correspondant?
Hors ligne
S'agit-il de fichiers *.spill? Si oui, il s'agit des fichiers générés lors du décodage logiques de grosses transactions (je ne vois d'ailleurs pas ce que cela pourrait être d'autre), et il s'agit du comportement attendu.
À priori, il n'y a pas vraiment d'alternative à part éviter de faire des grosses transactions si vous utilisez de la réplication logique, utiliser la réplication physique ou ajouter de l'espace disque.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Merci de l'attention que vous portez à mon soucis.
@tholot : le slot de réplication est bien interrogé par le client, j'avais suspecté cette piste mais il m'affirme avoir bien mis la souscription de son coté et ne pas y toucher. En temps normal, lorsqu'il n'y a pas de grosses requêtes en cours, je vois bien le retard de réplication se résorber petit à petit. Je n'ai pas trouvé (ou suis passé à coté) d'un paramètre permettant l'envois des fichiers de réplication avant COMMIT, si tu as le nom sous la main, je suis preneur !
@rjuju : il s'agit de fichier *.snap ; j'aimerais éviter de longue requêtes, mais malheureusement, on ne peut pas trouver traiter plusieurs centaines de millions de lignes en quelques secondes ^^. Lorsque je me suis renseigné, il m'a paru que seul la réplication logique permettait une réplication ciblé (juste un schéma, pas la base entière) ce que ne semble pas permettre la réplication physique. Je ne souhaite pas que mon client ait accès à l'entièreté de ma base. Tu me le confirmes ? Concernant l'espace disque, c'est à l'étude, mais seulement en dernier recours.
Merci,
Hors ligne
Je confirme, seule la réplication logique permet de ne répliquer qu'un sous ensemble des données.
Il n'est pas possible d'envoyer les fichiers de réplication avant le COMMIT puisque l'ordre réel d'application des modifications dépend du COMMIT.
S'agit-il d'énormément de fichier .snap, de fichiers très volumineux ou les deux ? Les fichiers .snap ont une taille qui dépend du nombre des transactions committées durant l'exécution d'une transaction, c'est donc probablement du à un très grand nombre de petites transactions d'un côté, et des transactions longues de l'autre.
on ne peut pas trouver traiter plusieurs centaines de millions de lignes en quelques secondes
Il est toujours possible d'effectuer le traitement par plus petits batch, en supposant que vous puissiez vous affranchir des garanties qu'apportent une unique transaction. La seule autre alternative serait d'utiliser un outil tiers de réplication logique, type slony/londiste. Cela appoarte malheureusement de nombreux autres inconvénients, notamment pour gérer le DDL.
Julien.
https://rjuju.github.io/
Hors ligne
Merci de me confirmer l'utilisation de la réplication logique pour limité la réplication du schéma, au moins je ne me suis pas trompé sur ce point.
Tholot m'a donné un petit espoir concernant l'envoi de fichier de réplication avant COMMIT, mais tu confirmes que ce que pensais avoir compris du fonctionnement de la réplication.
J'ai dû couper la réplication depuis cet incident (en attendant de solutionner soit ce problèmes de fichiers, soit améliorer les requêtes posant problèmes), mais de mémoire, c'était effectivement les deux : énormément de fichier .snap volumineux.
Je vais me pencher sur les solutions tiers ou voir les avantages qu'ils pourraient apporter.
Je te remercie pour tous ces éclaircissement.
Hors ligne
Juste pour être bien sûr, c'est bien normal cette accumulation de fichiers .snap malgré que les requêtes longues ne concerne pas les tables ni même le schéma répliqué ?
Hors ligne
Ah, je viens de voir que la différentiation .spill/.snap n'existe que depuis la version 12, et j'imagine que vous utilisez une version antérieure ?
Il est beaucoup plus probable qu'il s'agisse bien de la sérialisation d'une longue transaction en cours. Il n'est pas possible d'éviter cela, car cette sérialisation se fait au fur et à mesure et tant que la transaction n'est pas terminée il est impossible de prédire si celle-ci touchera certains objets ou non.
Julien.
https://rjuju.github.io/
Hors ligne
En effet, je tourne sur une version 10 de Postgres.
Un grand merci pour toutes ces précisions @rjuju, ça me permet d'y voir un peu plus clair.
Hors ligne
Pages : 1
