Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Installation » Mises à jour Linux sur serveur Postgresql 9.5 » 23/03/2016 14:55:59
Merci pour ta réponse
Tu as répondu "non" à la question "est-il recommandé de faire les mises à jour Linux" ou bien à la question "cela risque-t-il de faire planter Postgresql" ? ;-)
#2 Installation » Mises à jour Linux sur serveur Postgresql 9.5 » 23/03/2016 12:51:45
- jeff
- Réponses : 5
Bonjour
J'ai un serveur Postgresql 9.5 sous Linux CentOs 7
Postgresql 9.5 a été installé depuis la source tar.gz en compilant (make && make install)
Est-il recommandé de faire régulièrement les mises à jour des packages Linux ("yum update") sur le serveur, ou bien cela risque-t-il de faire planter Postgresql ou d'empêcher le redémarrage ?
Je précise qu'il s'agirait de mises à jour à chaud, sans arrêter Postgresql. Ou alors il est recommandé d'arrêter Postgresql pour faire les mises à jour OS ?
Merci
#3 Re : Réplication » Log shipping - WAL non rejoué sur le secours » 01/07/2015 08:52:03
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
#4 Re : Réplication » Log shipping - WAL non rejoué sur le secours » 10/06/2015 08:08:22
Comme c'est arrivé un week-end, je n'ai malheureusement pas pu tester un redémarrage du standby
Merci pour la réponse
#5 Réplication » Log shipping - WAL non rejoué sur le secours » 09/06/2015 09:12:51
- jeff
- Réponses : 3
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
Pages : 1