Forums PostgreSQL.fr

genio

Membre

pg_stop_backup qui tarde ...

rebonjour...
j'effectue un pg_start_backup (toto) => Ok
lorsque je fais mon pg_stop_backup ... voici les messages d'erreur :

Mabase=# SELECT pg_stop_backup ();
NOTICE:  pg_stop_backup cleanup done, waiting for required WAL segments to be archived
WARNING:  pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)
HINT:  Check that your archive_command is executing properly.  pg_stop_backup can be canceled safely, but the database backup will not be usable without all the WAL segments.

et ça continue jusqu'à ce que je cancelle...

Il semblerait que ce soit un problème dans mon archive_command, mais je ne vois pas pourquoi... pouvez-vous m'aider

Voici mon prostgresql.conf :
archive_command = 'cp %f /srv/pgsql/backup/%p'
archive_timeout = 360           # force a logfile segment switch after this

rjuju

Administrateur

Re : pg_stop_backup qui tarde ...

Il faut inverser les paramètres dans votre archive_commande :
cp %p /srv/pgsql/backup/%f

---

Julien.
https://rjuju.github.io/

genio

Membre

Re : pg_stop_backup qui tarde ...

Merci rjuju...
après modification des valeurs du archive_command, le problème persistait et en regardant la log j'ai vu qu'il manquait de la place  sur le l'arborescence cible... nous avons corrigé et c'est bon maintenant !

genio

Membre

Re : pg_stop_backup qui tarde ...

je suis en train de tester une restauration de database...
Le contexte : 1 instance avec deux databases TOTO (80 gigas) et TITI (200 Méga)
Hier soir :
pg_start_backup
cp de mes repertoire 'base' (fichier base.tar.gz ) et du répertoir x_log (xlog.tar.gz) donc 2 fichiers...
pg_stop_backup

Ce matin => Drop de la base toto

Cet aprèm => Je voudrais restaurer avant le drop de TITI donc la plus petite base => ok

1°) Dans la doc postgrès, ils parlent de : pg_create_restore_point()...  je n'ai pas compris pourquoi... faut-il l'exécuter en même temps que start-cp-et stop backup afin d'avoir un point d'ancrage ?

2°) Mon instance TITI étant ma base la plus petite, j'aimerai ne pas dropper mon repertoire 'base' (pour ensuite le remplacer par mon 'base.tar.gz') mais garder mon répertoire 'base' et juste rejouer les wal qui sont archivées... est-ce possible ?

Pouvez-vous m'aider

genio

Membre

Re : pg_stop_backup qui tarde ...

dans le paragraphe (ce maton => ...) C'était drop de la base TITI que je voulais écrire (donc de la plus petite )

rjuju

Administrateur

Re : pg_stop_backup qui tarde ...

1) Non, c'est utile uniquement si vous prévoyez une future restauration.
2) Non ce n'est pas possible.

Pour les sauvegarde niveau système de fichier, il faut copier toute l'arborescence, pas uniquement le répertoire base et pg_xlog. Si vous avez des tablespace il faut également les sauvegarder.

Il faut aussi comprendre que ce mode de restauration n'est pas possible pour un base spécifique mais se fait au niveau de l'instance. C'est également une sauvegarde destinée à une reprise sur incident, par pour de la restauration ponctuelle et sélective. Si vous avez toute l'arboresence du répertoire data d'hier (à la suite du pg_start_backup) ainsi que tous les wal qui ont été générés jusqu'au drop de la base TITI, vous pourrez la récupérer, mais cela veut dire que vous perdrez tout ce qui a pu être fait sur la base TOTO (ou n'importe quelle autre base) entre le drop et le moment ou vous faîtes la restauration.

Si vous ne voulez pas ce comportement, le seul moyen est de créer un nouveau serveur et faire la restauration du data, rejouer les wal jusqu'un peu avant le drop de TITI, puis dumper la base TITI pour la restaurer sur votre vraie instance.

Dernière modification par rjuju (24/05/2012 16:28:54)

---

Julien.
https://rjuju.github.io/

genio

Membre

Re : pg_stop_backup qui tarde ...

Merci rjuju pour vos explications...
Je trouve cela néanmoins pas très souple... car recharger complètement un environnement et ensuite rejouer les wal archivés pour par exemple, un drop malheureux sur une table, est très lourd a gérer...
Y aura t'il dans les versions suivantes de postgres quelques améliorations sur ce genre de problème ?

rjuju

Administrateur

Re : pg_stop_backup qui tarde ...

Non, car les wals sont communs à une instance. Même si un jour ils passent par database cela sera toujours problématique pour une seule table.
Si vous voulez une sauvegarde plus souple, il faut faire des dumps réguliers en mode custom, et la vous pourrez restaurer uniquement le ou les objets voulus. Mais bien sur en cas de drop d'une table vous ne pourrez restaurer une table qu'au moment du drop et perdrez ce qu'il y a eu entre temps.
Maintenant un drop malheureux n'est pas censé arriver fréquemment, sauf si tous les utilisateurs ont le droit de dropper des bases ou tables, auquel cas il faudrait revoir la politique de sécurité pour éviter cela.

---

Julien.
https://rjuju.github.io/

genio

Membre

Re : pg_stop_backup qui tarde ...

Ok pour le drop malheureux... c'est vrai que cela n'arrive pas tous les jours... jusqu'au jour où !
Bref, mon problème sur les dumps réguliers est que ma database fait 90 Gigas... et donc nous préférerions une formule comme start-cp-stop backup avec les wal à rejouer...
Je reprends ma question 1 : ais-je bien compris si je dis que Le pg_create_restore_point() pourrait donc être effectué disons toutes les heures,  pendant la journée de travail... en cas de restauration je pourrai ensuite choisir le point de synchro voulu ?

rjuju

Administrateur

Re : pg_stop_backup qui tarde ...

Oui, c'est le but de pg_create_restore_point(). Mais encore une fois cela remettra votre serveur au même état qu'au moment de l'appel, et donc tout ce qui a été fait après sera perdu. Cette fonction sert juste a définir un point dans le temps facilement retrouvable.

---

Julien.
https://rjuju.github.io/