Vous n'êtes pas identifié(e).
Pages : 1
Bonjour
J'ai une config log shipping simple avec 1 nominal et 1 secours, en version 9.0
Le nominal envoie les WALs par commande "scp"
Or, récemment, le secours s'est "figé" car il n'a pas pu rejouer un WAL (alors qu'il était bien présent)
Dans la log du secours, j'ai :
Jun 6 19:04:57 serveur_secours postgres[2082]: [167785-1] user=,db= LOG: restored log file "000000030000041B000000BB" from archive
Jun 6 19:05:02 serveur_secours postgres[2082]: [167786-1] user=,db= LOG: restored log file "000000030000041B000000BC" from archive
Jun 6 19:05:02 serveur_secours postgres[2082]: [167787-1] user=,db= LOG: restored log file "000000030000041B000000BD" from archive
Jun 6 19:05:02 serveur_secours postgres[2082]: [167788-1] user=,db= LOG: restored log file "000000030000041B000000BE" from archive
Jun 6 19:05:07 serveur_secours postgres[2082]: [167789-1] user=,db= LOG: restored log file "000000030000041B000000BF" from archive--> et puis plus rien après
Le WAL suivant (le 000000030000041B000000C0) était bien présent sur le secours, avait la même taille que les autres WALS (16777216 octets, donc à priori pas un problème de fichier corrompu suite un un problème réseau lors du transfert scp), mais n'a jamais était rejoué, comme si Postgresql n'avait pas vu qu'il était là
Contenu de mon fichier recovery.conf sur le secours :
restore_command='/apps/pgsql/9.0/bin/pg_standby -d -k 255 -t /home/postgres/stoprestore_9.0.file /datas/pglogs/9.0/shipped_logs/ %f %p >>/logs/pgsql/log_shipping/9.0/pg_standby.log 2>>/logs/pgsql/log_shipping/9.0/pg_standby.log'Contenu du fichier pg_standby.log :
Trigger file : /home/postgres/stoprestore_9.0.file
Waiting for WAL file : 000000030000041B000000BD
WAL file path : /datas/pglogs/9.0/shipped_logs//000000030000041B000000BD
Restoring to : pg_xlog/RECOVERYXLOG
Sleep interval : 5 seconds
Max wait interval : 0 forever
Command for restore : cp "/datas/pglogs/9.0/shipped_logs//000000030000041B000000BD" "pg_xlog/RECOVERYXLOG"
Keep archive history : 000000030000041A000000BD and later
running restore : OK
Trigger file : /home/postgres/stoprestore_9.0.file
Waiting for WAL file : 000000030000041B000000BE
WAL file path : /datas/pglogs/9.0/shipped_logs//000000030000041B000000BE
Restoring to : pg_xlog/RECOVERYXLOG
Sleep interval : 5 seconds
Max wait interval : 0 forever
Command for restore : cp "/datas/pglogs/9.0/shipped_logs//000000030000041B000000BE" "pg_xlog/RECOVERYXLOG"
Keep archive history : 000000030000041A000000BE and later
running restore : OK
Trigger file : /home/postgres/stoprestore_9.0.file
Waiting for WAL file : 000000030000041B000000BF
WAL file path : /datas/pglogs/9.0/shipped_logs//000000030000041B000000BF
Restoring to : pg_xlog/RECOVERYXLOG
Sleep interval : 5 seconds
Max wait interval : 0 forever
Command for restore : cp "/datas/pglogs/9.0/shipped_logs//000000030000041B000000BF" "pg_xlog/RECOVERYXLOG"
Keep archive history : 000000030000041A000000BF and later
WAL file not present yet. Checking for trigger file...
running restore : OK--> Et puis plus rien après
Pourtant rien d'anormal s'est passé sur le serveur (pas de filesystem plein, pb réseau, pb mémoire ou autre)
Quelqu'un a-t-il déjà rencontré un problème similaire ?
Y a-t-il d'autres logs et/ou traces que je peux activer pour avoir + d'infos si le problème se reproduit ?
Merci d'avance
Hors ligne
Quelqu'un a-t-il déjà rencontré un problème similaire ?
Pas de souvenir en tout cas.
Y a-t-il d'autres logs et/ou traces que je peux activer pour avoir + d'infos si le problème se reproduit ?
Pas à ma connaissance. pg_standby est un outil très simple. Le seul truc que je vois serait de redémarrer le standby. Peut-être qu'il détectera la présence du fichier.
Guillaume.
Hors ligne
Comme c'est arrivé un week-end, je n'ai malheureusement pas pu tester un redémarrage du standby
Merci pour la réponse
Hors ligne
Pour info le même problème s'est reproduit ce matin
J'ai eu le temps de tester un redémarrage de Postgresql sur le secours et la réplication a bien repris
Bizarre quand-même, peut-être un bug dans la version 9.0, car j'ai d'autres serveurs en log shipping avec config identique mais en version plus récente (>=9.1) et je n'ai jamais rencontré ce problème
Hors ligne
Pages : 1