Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Nous travaillons à la migration d'une base de données de 40 Go, d'un moteur 8.2.4 à 9.2.4 sous CentOS 5.9.
Dans le fichier postgresql.conf, nous avons défini le checkpoint_segments à 32. Toutefois dans le répertoire pg_xlog, je vois 66 fichiers.
Est-ce que la valeur du paramètre n'est pas assez haute ?
Est-ce que PostgreSQL utilise "un peu" plus de fichiers au besoin ?
Nous allons activer l'archivage des fichiers wal, et le week-end, nous allons faire tourner un script de maitenance qui effectue :
- vacuumdb -a -f -z
- reindexdb -a
Cela va t'il généré davantage de fichiers dans pg_xlog ? ou est-ce uniquement le répertoire des logs archivés qui va grossir ?
Notre script de maintenance est-il toujours d'actualité en 9.2, à savoir faut-il toujours faire un vacuum full ? et un reindex de toutes les bases ?
D'avance merci pour les réponses.
Hors ligne
> Est-ce que la valeur du paramètre n'est pas assez haute ?
Impossible à répondre. Si votre idée est qu'avec un checkpoint_segments à 32, vous ne devriez avoir que 32 fichiers, vous vous trompez. Vous aurez en temps normal au maximum 3*checkpoint_segments+1 (97 dans votre cas). Et plus s'il y a plein d'activité...
> Est-ce que PostgreSQL utilise "un peu" plus de fichiers au besoin ?
Oui, en effet.
> Cela va t'il généré davantage de fichiers dans pg_xlog ?
Ah oui, un VACUUM FULL et un REINDEX va générer énormément de WAL.
> ou est-ce uniquement le répertoire des logs archivés qui va grossir ?
Lui aussi va grossir.
Guillaume.
Hors ligne
Bonjour Guillaume,
Effectivement, je n'avais pas compris.
Pouvez-vous me dire pourquoi "3*" ?
Sur ma base de 40Go, si je fais un vacuum full puis un reindex, est-il possible de prévoir le volume d'occupation disque que cela va engendrer dans pg_xlog ? et dans le répertoire des logs archivés ?
J'espère ne pas trop monopoliser de votre temps et encore merci pour votre aide.
Hors ligne
Bonjour Guillaume,
Pouvez-vous me dire pourquoi "3*" ?
Parce que si l'activité est "normale", au delà de ce seuil, Postgresql supprimera les fichiers WAL supplémentaires dont il n'aurait plus besoin et en deça de cette limite, il les recyclera plutôt.
Hors ligne
Bonjour Pitpoule,
Merci pour votre réponse.
Avez-vous une réponse pour ma deuxième question ?
Hors ligne
Très exactement, c'est "(2+checkpoint_completion_timeout)*checkpoint_segments + 1". Avant ce seuil, PostgreSQL renomme ceux dont il n'a plus besoin. Après ce seuil, comme dit pitpoule, il supprime ceux en trop dont il n'a plus besoin.
Quant à la question de la volumétrie, non, il n'est pas possible de prévoir ce que cela va engendrer. D'ailleurs plus checkpoint_segments est petit, et plus la quantité d'informations à enregistrer dans les WAL est importante. Comme on ne peut pas prévoir le nombre de WAL générés, on ne peut pas plus savoir pour les archivés (en dehors du fait qu'il s'agira du même volume).
Guillaume.
Hors ligne
Pages : 1
