Vous n'êtes pas identifié(e).
Pages : 1
Bonjour tout le monde,
Tout d'abord vu la situation actuelle, j'espère que vous allez tous bien ainsi que vos entourages respectifs.
Je suis en quête d'une méthode et/ou un outil qui réorganise les relations de la base PostgreSQL et qui m'épargne les désagréments de VACUUM FULL à savoir les locks avec des bases de données de plus en plus exigeants en terme de disponibilité.
L’extension pg_repack, est un bon compromis, mais à part l'espace disque à fournir en plus pour le faire fonctionner. Ceci n'est pas très grave, le support magnétique n'est pas ce qui coûte le plus chère.
Le problème c'est qu'en cherchant, je trouve une publication de "DALIBO" disant ceci "pg_repack étant très intrusif et ayant déjà affiché des bugs de corruption de données, nous déconseillons fortement son utilisation." Fin de Citation.
A savoir que pour les versions <=1.1.8, il ne faut pas lancer des DDL au moment ou pg_repack fait sont travail car il y a un risque sérieux de corruption de données à défaut d'un rollback.
Ma question est : La recommandation de BALIBO concerne t elle les anciennes version ou elle est toujours d'actualité.
Est ce que quelqu'un utilise l’outil "pg_repack en production "surtout pour des base à grande taille >=500Go, pourra partager son/ses expérience.
Par avance merci
Hors ligne
Bonjour,
Si quelqu'un pourra me dire quelque chose à ce sujet.
Par avance merci
Hors ligne
Je fais partie de Dalibo mais je vais répondre quand même. En allant simplement sur le GitHub du projet: Aucun commit depuis le 1er octobre. 61 tickets en attente. Aucune réponse depuis août 2020. Quelques tickets au titre évocateur : "repack_apply() with bogus arguments causes engine crash", "repack broken in the presence of an ALL TABLES publication set", "query failed: server closed the connection unexpectedly". Ça donne moyennement confiance.
Pas d'expérience sur l'outil, donc je ne pourrais pas aller plus loin.
Guillaume.
Hors ligne
De plus, si vous avez besoin d'effectuer régulièrement des VACUUM FULL (ou équivalent), c'est dans la majorité des cas une mauvaise configuration d'autovacuum ou un manque de VACUUM manuel dans certains traitements.
Julien.
https://rjuju.github.io/
Hors ligne
Merci Guillaume merci Julien d'avoir pris le temps pour me répondre.
Par ailleurs, dans le cas d'une base volumineuse ou une autre qui devra être disponible 7/24, Comment peut-on pallier aux problème de fragmentation et l'organisation des lignes mortes des tables.
Comment prévoyez vous la récupération la récupération de l'espace disque?
@Julien, est ce que je comprend qu'une bonne configuration d'autuvacuum est capable de nous épargner tout ça?
Par avance meci.
Hors ligne
@Julien, est ce que je comprend qu'une bonne configuration d'autuvacuum est capable de nous épargner tout ça?
Tout dépdend ce que vous entendez par "ça". L'autovacuum est censé éviter un bloat excessif dans la majorité des cas, et des VACUUM manuels pour les cas où autovacuum ne peut pas fonctionner (transaction longue par exemple). Le seul cas ou un VACUUM FULL est vraiment nécessaire est la suppression ou mise à jour d'une très grande partie de la table.
Julien.
https://rjuju.github.io/
Hors ligne
Donc au final si on a besoin de regagner de l'espace disque occupé par des lignes "vides" dans les tables, il faut faire un VACUUM FULL.
1- De ce fait, même avec un paramétrage bien fait de l'autovacuum, on est obligé de faire le VACUUM FULL; même avec espacement important 1 fois par mois, trimestre...?
et si l'autovacuum ralenti la vitesse du "bloat" s'il est bien paramétré?
2- Si on se concentre sur la question de l'autovacuum et le faire d'une façon optimale est ce qu'on aura le résultat attendu au niveau performance? (bien évidemment associé avec le tuning ressources matériel, moteur BDD, code SQL...etc.)
Hors ligne
Je ne suis pas certain que vous attaquiez le problème sous le bon angle. Tout d'abord, avoir du bloat est inévitable et est même recommandé. Cet espace inutilisé permet des optimisations type HOT.
Le vrai problème n'est pas d'avoir 1%, 5%, 10% ou n'importe quel ratio de bloat, le problème est d'avoir un ratio de bloat qui grandit constamment. Avec une bonne configuration d'autovacuum et des appels à VACUUM dans les cas nécessaires, vous devriez avoir un ratio stable et donc pas de besoin de faire de VACUUM FULL, sauf dans les cas extrêmes ou vous réécrivez la presque totalité de la table, ce qui revient à avoir par exemple 90% de bloat, qui certes sera réutilisé à terme, mais pourrait prendre des mois ou des années.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1
