Vous n'êtes pas identifié(e).
Pages : 1
bonjour à tous
sur une de mes bases, je viens d'avoir le message suivant :
FATAL: database is not accepting commands to avoid wraparound data loss in database "mydb"
HINT: Stop the postmaster and use a standalone backend to vacuum database "mydb".
je ne peux donc plus lancer de vacuum en live (connexion refusée). je l'ai donc lancé en offline via :
/usr/lib/postgresql/8.1/bin/postgres -D /var/lib/postgresql/8.1/main/ mydb < /tmp/vacuum.sql
la base est assez conséquente (~ 500 Go). je voulais savoir :
1) puis-je arrêter la vaccum offline sans risque de perte de data ?
2) puis-je lancer d'autres commandes en offline sans risque de perte de data ?
merci d'avance !
Hors ligne
Bonjour,
1) Vous pouvez arrêter le vacuum mais tant qu'il ne sera pas fini vous ne pourrez pas utiliser votre database.
2) Cette erreur est justement là pour vous empêcher de perdre des données. Toute nouvelle transaction sera refusée tant que le vacuum n'aura pas été effectué. Voir le paragraphe 22.1.3 http://docs.postgresql.fr/8.1/maintenance.html
Vous devriez également prévoir la mise en place de vacuum régulier, ou activer l'auto vacuum (si version >= 8.1)
Julien.
https://rjuju.github.io/
Hors ligne
salut rjuju et merci pour ta réponse rapide, j'ai qq précisions à demander
1) est-ce que si j'arrête le vacuum et que je le relance, il reprend là où il s'était arrêté ?
2) avec le backend postgres ("moteur autonome") j'arrive bien à lancer la commande VACUUM donc je me demandais si je pouvais lancer d'autres commandes (ex : dump de la base ou autres)
merci !
Hors ligne
1) Non, si vous arrêtez le traitement le début du travail sera annulé comme pour n'importe quelle autre transaction.
2) Vous pouvez dans tous les cas arrêter le serveur et faire une sauvegarde du répertoire data. Pour le dump je ne sais pas, je n'ai jamais été confronté au problème. Si vous n'avez jamais fait de vacuum il est probable que la taille du répertoire data soit bien plus importante que ce qu'elle devrait (selon le nombre d'update et delete). Quand vous arriverez à redémarrer le serveur il serait peut-être intéressant de lancer des vacuum full analyze sur les tables les plus fragmentées afin de récupérer de l'espace.
Dernière modification par rjuju (24/05/2012 14:13:58)
Julien.
https://rjuju.github.io/
Hors ligne
ok merci !
Hors ligne
Pour infos, vous ne pouvez pas lancer de backup en mode mono-utilisateur vu que, comme son nom l'indique, vous n'avez le droit qu'à une connexion (que vous occupez déjà), or pg_dump en utiliserait une deuxième.
Guillaume.
Hors ligne
Pages : 1
