Vous n'êtes pas identifié(e).
Pages : 1
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.
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é ?
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.
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,
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,
Pages : 1
