Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Petite question bête.
Je me suis mis sur un pg 8.3 en mode archivelog.
Bon, j'avoue, j'ai merdé dans la commande d'archivage, donc du coup il signalait l'erreur dans le var/log
J'ai corrigé la commande, redémarré le serveur. Les anciens logs ont bien été transférés sur le FS d'archivage.
Mais ils sont toujours présents également dans pg_xlog...
Ils sont supposés être purgés de pg_xlog au bout d'un moment, ou bien il va falloir que je donne dans le pg_resetxlog ?
Dernière modification par herve.lefebvre (08/12/2010 13:12:52)
Hors ligne
Jamais de pg_resetxlog. C'est une commande à réserver aux cas désespérés de corruption.
Les fichiers vont disparaître automatiquement de pg_xlog, au prochain checkpoint (toutes les 5 minutes par défaut).
Marc.
Hors ligne
OK, effectivement un psql -c "CHECKPOINT;" a vidé le pg_xlog.
Merci.
Hors ligne
Bon, je suis toujours dans mes tests d'archivelog.
J'ai testé le cas suivant :
1) Sauvegarde
2) grosse insertion dans la base
3) simulation de crash disk (rm -rf de toutes les données y compris pg_xlog).
Entre 1) et 3) il ne sest pas écoulé assez de temps pour qu'il y ait un checkpoint. Par contre entre 1) et 3) il y a des logs qui sont partis de pg_xlog vers mon archive-log.
Le recovery plante, parce qu'il ne trouve pas le dernier log (qui se trouvait dans le pg-xlog et qui a donc été perdu) :
2010-12-09 17:55:21 CET%%LOCATION: StartupXLOG, xlog.c:4819
2010-12-09 17:55:21 CET%%LOG: 00000: starting archive recovery
2010-12-09 17:55:21 CET%%LOCATION: readRecoveryCommandFile, xlog.c:4377
2010-12-09 17:55:21 CET%%LOG: 00000: restore_command = 'test ! -f /data/postgresql/archlog/%f && cp /data/postgresql/archlog/%f %p'
2010-12-09 17:55:21 CET%%LOCATION: readRecoveryCommandFile, xlog.c:4423
2010-12-09 17:55:21 CET%%LOG: 00000: recovery_target_time = '2010-12-09 16:56:00+01'
2010-12-09 17:55:21 CET%%LOCATION: readRecoveryCommandFile, xlog.c:4481
2010-12-09 17:55:21 CET%%LOG: 00000: recovery_target_inclusive = false
2010-12-09 17:55:21 CET%%LOCATION: readRecoveryCommandFile, xlog.c:4496
cp: cannot stat `/data/postgresql/archlog/00000001.history': No such file or directory
cp: cannot stat `/data/postgresql/archlog/000000010000003600000003': No such file or directory
2010-12-09 17:55:21 CET%%LOG: 58P01: could not open file "pg_xlog/000000010000003600000003" (log file 54, segment 3): No such file or directory
2010-12-09 17:55:21 CET%%LOCATION: XLogFileRead, xlog.c:2365
2010-12-09 17:55:21 CET%%LOG: 00000: invalid primary checkpoint record
2010-12-09 17:55:21 CET%%LOCATION: ReadCheckpointRecord, xlog.c:5399
cp: cannot stat `/data/postgresql/archlog/000000010000003600000003': No such file or directory
2010-12-09 17:55:21 CET%%LOG: 58P01: could not open file "pg_xlog/000000010000003600000003" (log file 54, segment 3): No such file or directory
2010-12-09 17:55:21 CET%%LOCATION: XLogFileRead, xlog.c:2365
2010-12-09 17:55:21 CET%%LOG: 00000: invalid secondary checkpoint record
2010-12-09 17:55:21 CET%%LOCATION: ReadCheckpointRecord, xlog.c:5403
2010-12-09 17:55:21 CET%%PANIC: XX000: could not locate a valid checkpoint record
2010-12-09 17:55:21 CET%%LOCATION: StartupXLOG, xlog.c:4924
2010-12-09 17:55:21 CET%%LOG: 00000: startup process (PID 3623) was terminated by signal 6: Aborted
2010-12-09 17:55:21 CET%%LOCATION: LogChildExit, postmaster.c:2540
2010-12-09 17:55:21 CET%%LOG: 00000: aborting startup due to startup process failure
2010-12-09 17:55:21 CET%%LOCATION: reaper, postmaster.c:2113
Je trouve ça un peu étrange, parce que même si je mets un recovery_target_time situé entre les étapes 1 et 2, avec recovery_target_inclusive = 'false' , le recovery plante quand même.
C'est un comportement normal ?
Cela voudrait dire qu'après un backup il faudrait systématiquement faire un CHECKPOINT pour être certain que la sauvegarde sera utilisable ?
Dernière modification par herve.lefebvre (09/12/2010 19:13:28)
Hors ligne
Après le backup, avez vous fait un pg_stop_backup() ?
Marc.
Hors ligne
Ben il me semble bien que oui...
D'ailleurs, il a bien généré le 0000...EF.backup qui semble correct.
Hors ligne
Ok, alors point suivant à vérifier: cette archive introuvable n'a t'elle pas été générée pendant le backup (avant le pg_stop_backup() ) ?
On a besoin de toutes les archives générées PENDANT le backup (dont la dernière, qui est générée durant le pg_stop_backup() ).
Marc.
Hors ligne
Ok, alors point suivant à vérifier: cette archive introuvable n'a t'elle pas été générée pendant le backup (avant le pg_stop_backup() ) ?
On a besoin de toutes les archives générées PENDANT le backup (dont la dernière, qui est générée durant le pg_stop_backup() ).
Ok ; ça doit être ça alors.
Est-ce qu'un CHECKPOINT après le pg_stop_backup() me garantira du coup qu'a la fin du batch de sauvegarde, il peut se passer n'importe quoi dans les minutes qui suivent, on a de quoi restaurer la base ?
Edit : Ben non, ça peut pas être ça en fait.
Parce que j'ai fait la sauvegarde, et après j'ai fait un DROP TABLE TOTO qui contenait 10 millions de lignes ; puis un CREATE TABLE TITI avec ensuite l'insertion de 5 millions de lignes.
Ca m'a généré une bone douzaines de WAL dont seul le dernier n'a pas été archivé.
C'est après ça que j'ai fait mon rm -rf des fichiers data.
Finalement, j'ai testé pg_resetxlog pour voir ^ ^ ; ça a bien marché, et j'ai récupéré la base sans la table toto, mais avec la table titi complète (5 millions de lignes).
Bon, je vais retester ça demain matin...
Dernière modification par herve.lefebvre (09/12/2010 22:41:26)
Hors ligne
pg_stop_backup execute déjà un checkpoint.
Ne touchez pas à pg_resetxlog, ce n'est pas fait pour ça. Vous n'avez aucune garantie de cohérence des données après cette commande. Ce n'est pas parce que cette commande ne vous retourne pas d'erreurs que vous n'aurez pas de problème.
Après y avoir regardé de plus près, êtes vous sûr de votre restore_command ?
'test ! -f /data/postgresql/archlog/%f && cp /data/postgresql/archlog/%f %p'
=> Cela teste si le chemin demandé est un fichier. Si ce n'en est pas un, cela effectue la recopie. Je présume que ce n'est pas vraiment ce que vous souhaitez faire.
Contentez vous du cp. Le test n'a aucun intérêt de toutes façons, cp retournera une erreur que PostgreSQL interprétera, si le fichier n'est pas là
Marc.
Hors ligne
Ne touchez pas à pg_resetxlog, ce n'est pas fait pour ça. Vous n'avez aucune garantie de cohérence des données après cette commande.
Oui oui, j'ai bien compris ^^ Mais comme dit plus haut, je ne fais que des tests, j'en ai profité pour voir comment marchait resetxlog.
Après y avoir regardé de plus près, êtes vous sûr de votre restore_command ?
Gronk ! Je l'avais sous les yeux mais je ne lisais que ce que j'était persuadé avoir écrit, et non pas ce que j'avais réellement écrit...
Merci.
Hors ligne
Ok pour le resetxlogs. C'est juste que vu que c'est un forum, il vaut mieux ne pas laisser trainer de 'fausses bonnes idées', au cas où quelqu'un ferait une recherche 
Marc.
Hors ligne
Pages : 1
