Vous n'êtes pas identifié(e).
Pages : 1
bonjour,
j'essaie de tester la replication avec la version 8.3 de postgresql.
pour ce faire j'ai un service "replication" sur la machine slave qui la lance.
ce service positionne sur le maitre l'archiving par une commande ssh :
archive_mode = on
# (change requires restart)
archive_command = '/usr/bin/archivage.sh %p %f'
puis relance le service.
le script /usr/bin/archivage.sh fait notamment:
scp $p ${SLAVE}:/var/lib/pgsql/xlog_maitre/$f et logge le resultat dans un fichier de log.
le service replication sur l'esclave lance un backup sur le maitre par un script qui execute les actions suivantes:
psql -c "SELECT pg_start_backup('label')" postgres
scp -r /var/lib/pgsql/data ${SLAVE}:/var/lib/pgsql &> $LOG
psql -c "SELECT pg_stop_backup()" postgres &> $LOG
puis copy le fichier recovery.conf sur le repertoire /var/lib/pgsql/data de l'esclave
(contenu du fichier : )
restore_command = '/usr/bin/restauration.sh %f %p'
/usr/bin/restauration.sh:
#!/bin/sh
#
f=$1
p=$2
MASTER="arm-db"
SLAVE="arm-sp"
DATE=$(date +"%Y-%m-%d %H:%M:%S")
LOG=/var/log/postgresql/restauration.log
LOGDEBUG=/var/log/postgresql/restaurationDebug.log
pg_standby -k 100 -t /tmp/stopstandby /var/lib/pgsql/xlog_maitre $f $p >> $LOGDEBUG
RETVAL=$?
if $RETVAL -eq 0
then
echo "$DATE LOG : journal $f restauration " >> $LOG
else
echo "$DATE ERROR : journal $f restauration problem" >> $LOG
fi
le service de replication lance enfin le service postgres sur l'esclave.
Ce que je constate est:
les fichiers WAL sont bien envoyés sur l'esclave, mais ne sont pas correctement traités par celui ci
Dans mon fichier restauration.log , j'ai en effet :
2012-03-08 09:26:45 ERROR : journal 0000000100000000000000AF restauration problem
la commande pg_standby retourne une valeur différente de 0
Par contre, dans le fichier LOGDEBUG=/var/log/postgresql/restaurationDebug.log
je ne vois aucune ligne
Comment puis-je diagnostiquer pourquoi j'ai un problème de restauration ?
Merci de votre aide.
Hors ligne
Vous pouvez déjà commencer par rajouter un 2>&1 à la fin de votre commande pg_standby pour récupérer aussi son stderr dans $LOGDEBUG, cela vous permettra peut-être de récupérer le message d'erreur.
Sinon, difficile de vous dire comme ça ce qui ne va pas. Ça semble être bon, mais en script shell, chaque caractère compte et peut être la cause d'une erreur 
Marc.
Hors ligne
avec le 2>&1 positionné, j'ai le massage suivant dans le fichier /var/log/postgresql/RestaurationDebug.log:
cp: cannot stat `/var/lib/pgsql/xlog_maitre/00000001.history': No such file or directory
cp: cannot stat `/var/lib/pgsql/xlog_maitre/00000001.history': No such file or directory
ce fichier n'est pas contenu dans le pg_xlog du maitre
Pourquoi pg_standby cherche t il a acceder à ce fichier ?
Il semblerait cependant que malgré ce compte rendu negatif du retour de pg_standby,
les wal buffers soient bien copiés dans la database esclave, si j'arrête le processus de replication
Dernière modification par mlecot (08/03/2012 15:42:30)
Hors ligne
Ah. C'est un bug (mineur, la plupart du temps) de la 8.3, ça a été corrigé depuis. Effectivement, il faudra prévoir d'ignorer ce fichier dans votre script.
À chaque fois qu'on fait une récupération partielle (un PITR) et qu'on ouvre la base, ça crée une nouvelle timeline, donc un nouveau fichier history. Sauf évidemment pour la timeline 1, qui est celle créée au départ. Le fichier 000001.history n'existe pas, mais c'est normal. PostgreSQL lui même ignore cette erreur. Donc soit vous vérifiez dans votre script qu'on vous demande ce fichier, et vous l'ignorez, soit vous vous arrangez pour que votre script retourne $RETVAL comme code retour, que PostgreSQL puisse s'en sortir. Le code retour de ces scripts est capital.
Marc.
Hors ligne
Merci beaucoup pour cette réponse claire et rapide
Hors ligne
Pages : 1
