Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je teste la sauvegarde à chaud (service en ligne) et la restoration aprés un crash en rejouant les fichiers WAL.
1er cas)
Backup A ____ M a J diverses ____ crash
je restore le tar du backup A je mets le fichier recovery.conf et c'est ok
2em cas)
Backup A ___ M aJ diverse ___ crash ___ restore de A (ok) ____M a J ____ Backup B ____ M a J____ crash
et je veux restorer toujours du Backuo A ( pas du B, imaginons véreux). Par contre j'ai tous les journaux WAL deuis le backup A. Donc fichier recovery.conf et là le démarrage du service postgresql ECHOUE !!! ...
16:02:26 v221ent-db1test postgres[4525]: [1-1] LOG: could not create IPv6 socket: Address family not supported by protocol
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [2-1] LOG: database system was interrupted; last known up at 2009-10-21 13:37:50 CEST
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [3-1] LOG: starting archive recovery
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [4-1] LOG: restore_command = 'cp /SauvArchiWAL/%f %p'
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [5-1] LOG: restored log file "00000003.history" from archive
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [6-1] LOG: restored log file "00000003000000000000008F.00000208.backup" from archive
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [7-1] LOG: restored log file "00000003000000000000008F" from archive
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [8-1] LOG: automatic recovery in progress
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [9-1] LOG: record with zero length at 0/8F000250
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [10-1] LOG: redo is not required
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [11-1] LOG: restored log file "00000003000000000000008F" from archive
Oct 21 16:02:26 v221ent-db1test postgres[4528]: [12-1] FATAL: WAL ends before end time of backup dump
Oct 21 16:02:26 v221ent-db1test postgres[4525]: [2-1] LOG: startup process (PID 4528) exited with exit code 1
Oct 21 16:02:26 v221ent-db1test postgres[4525]: [3-1] LOG: aborting startup due to startup process failure
Une idée ... ? Merci d'avance
Cdtl
G.
Hors ligne
Non parce que je n'ai rien compris aux « Backup A ____ M a J diverses ____ crash » et « Backup A ___ M aJ diverse ___ crash ___ restore de A (ok) ____M a J ____ Backup B ____ M a J____ crash ». Vous pouvez expliquer un peu plus ce que cela veut dire ?
Guillaume.
Hors ligne
Je vais essayer d'être plus clair,
Backup A _____ M a J divers ____ crash
ceci est la suite des opérations que je fais dans le temps, j'explicite :
je fais un backup (un tar encadré d'un pg_start_backup et d'un pg-stop_backup) pendant que postgres tourne, puis je fais des Mises à Jour des tables de la base, puis je simule un crash (j'arrete postgres et je restore le tar fait précedemment). Au 1er restore que je fais tout va bien postgres redemarre et je retrouve les mises à jour faites entre le backup nommé A et le crash. Ensuite je refais des mises à jours puis un autre backup nommé B, d'autres mises à jours et encore un crash disque. Le problème est que j'imagine que mon backup B soit perdu, donc je repars de mon backup A et de plus j'ai gardé tous les journaux WAL faits depuis ce backup A. Mais une fois ce backup restoré le processus postgresql ne redémarre plus. Voilà mon souci...
A+
Dernière modification par Gil34 (21/10/2009 21:12:05)
Hors ligne
À priori, PostgreSQL doit pouvoir restaurer tout jusqu'au backup B. Parce qu'après le backup B, vous vous retrouvez sur une autre timeline, ce qui fait que vos journaux de transactions suivants ne sont plus utilisables.
Guillaume.
Hors ligne
En pratique, faudrait que je fasse quoi pour restaurer à partir du backup A (fait en 1er) ???
Merci de votre aide
Cdlt
G.
Hors ligne
Pour restaurer à partir du backup A jusqu'au moment du crash final, en ayant fait une restauration au milieu comme expliqué, il faut préciser dans le recovery.conf qu'on veut restaurer sur la timeline d'après la première tentative de restauration. On voit la timeline dans le nom des fichiers archivés : c'est le numéro qui a été incrémenté dans le nom des journaux archivés, après le succès de la première restauration
Il faut donc préciser cette recovery_target_timeline, afin qu'il sache récupérer les bonnes versions journaux (celles de la seconde timeline, après la première restauration)
Marc.
Hors ligne
Merci de cette réponse, j'ai fait un essai et j'ai les mêmes messages.
Quand le backup A a été fait il a créé un fichier :
00000003000000000000008F.00000208.backup
dedans il y a :
START WAL LOCATION: 0/8F000208 (file 00000003000000000000008F)
STOP WAL LOCATION: 0/8F000270 (file 00000003000000000000008F)
CHECKPOINT LOCATION: 0/8F000208
START TIME: 2009-10-21 13:37:50 CEST
LABEL: backtestGil
STOP TIME: 2009-10-21 13:38:08 CEST
est ce que la taget_timelien a mettre est bien 00000003000000000000008F ??? c'est ce que j'ai mis...
j'ai aussi un fichier 00000003.history et 00000004.history ....
avec dedans:
1 00000001000000000000007A before transaction 0 at 2000-01-01 01:00:00+01
2 000000020000000000000080 before transaction 0 at 2000-01-01 01:00:00+01
et pour le 0000004 :
1 00000001000000000000007A before transaction 0 at 2000-01-01 01:00:00+01
2 000000020000000000000080 before transaction 0 at 2000-01-01 01:00:00+01
3 000000030000000000000090 before transaction 0 at 2000-01-01 01:00:00+01
Encore grand merci de votre aide ....
A+
G.
Dernière modification par Gil34 (22/10/2009 18:17:18)
Hors ligne
La timeline, c'est 3: c'est le compteur qui est incrémenté à chaque restauration 'partielle' (à partir des archives)
Marc.
Hors ligne
J'essaie lundi et vous tiens au courant.
Bon week
A+
G.
Hors ligne
Merci beaucoup Marc, effectivement avec le bon : recovery_target_timeline dans le recovery.conf, ça marche impeccable.
A+
Cdlt
Gilbert
Hors ligne
Pages : 1
