pg_standby - wall shipping

Salut,

J'essaie en vain de mettre en place une solution de wal shipping mais je galère. J'ai pour l'instant mis en route un premier serveur, le master, ce dernier possède son postgres et il envoie par scp les wal sur le serveur de secours. Les fichiers arrivent correctement dans le répertoire /home/postgres/archivewal de mon serveur de secours et sont propriété de l'utilisateur postgres. J'ai essayé de mettre en place le recovery.conf avec restore_command = 'pg_standby /home/postgres/archivewal %f %p %r 2>> /tmp/pg_standby.log' comme commande de restauration. Après quelques minutes de génération de wal par le master, je relance le serveur de secours pour qu'il se synchronise avec le master mais rien ne se passe. Pas de message d'erreur mais pas non plus de synchronisation et mon recovery.conf se renomme automatiquement en recovery.done.

Où se trouve mon erreur?

Je ne sais pas si ça importe mais je suis sous RHEL5.

Qu'as-tu dans le fichier de log du serveur postgresql ?
Comment as-tu copié la base de secours avant de lancer la synchronisation ?

Salut,

J'ai modifié mon archive_command et le log de postgres me dit ceci :

Citation:

---

[ 2008-08-06 12:04:54.581 CEST :] LOG: database system was shut down at 2008-08-06 12:01:47 CEST
[ 2008-08-06 12:04:54.581 CEST :] LOG: starting archive recovery
[ 2008-08-06 12:04:54.581 CEST :] LOG: restore_command = "/usr/local/pgsql/bin/pg_standby -s 60 -m -d -t /tmp/standby.trigger /home/postgres/archivedir %f %p 2>> pg_log/standby.log"

---

Par contre, j'ai beau générer du mouvement dans la base master, rien n'y fait, lorsque je coupe la restauration et que je repasse en mode "normal", je ne retrouve pas mes modif.

le standby.log contient :

Citation:

---

Trigger file : /tmp/standby.trigger
Waiting for WAL file : /home/postgres/archivedir/00000006.history
WAL file path : 00000006.history
Restoring to... : pg_xlog/RECOVERYHISTORY
Sleep interval : 60 seconds
Max wait interval : 600 seconds
Command for restore : mv /home/postgres/archivedir/00000006.history pg_xlog/RECOVERYHISTORY
running restore : history file not found

Trigger file : /tmp/standby.trigger
Waiting for WAL file : /home/postgres/archivedir/000000060000000000000051
WAL file path : 000000060000000000000051
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 60 seconds
Max wait interval : 600 seconds
Command for restore : mv /home/postgres/archivedir/000000060000000000000051 pg_xlog/RECOVERYXLOG
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...timed out after 659 seconds

Trigger file : /tmp/standby.trigger
Waiting for WAL file : /home/postgres/archivedir/00000007.history
WAL file path : 00000007.history
Restoring to... : pg_xlog/RECOVERYHISTORY
Sleep interval : 60 seconds
Max wait interval : 600 seconds
Command for restore : mv /home/postgres/archivedir/00000007.history pg_xlog/RECOVERYHISTORY
running restore : history file not found

Trigger file : /tmp/standby.trigger
Waiting for WAL file : /home/postgres/archivedir/00000006.history
WAL file path : 00000006.history
Restoring to... : pg_xlog/RECOVERYHISTORY
Sleep interval : 60 seconds
Max wait interval : 600 seconds
Command for restore : mv /home/postgres/archivedir/00000006.history pg_xlog/RECOVERYHISTORY
running restore : history file not found

---

Pour la mise en place du master sur le test, j'ai fait ceci :

Code:

---

1 2 3 4 5

sur le master : psql template1 -U postgres -c "SELECT pg_start_backup('sauve_1')" tar cvfj pgdata.tar.bz2 /usr/local/pgsql/data psql template1 -U postgres -c "SELECT pg_stop_backup()"

---

Et j'ai remplacé le data du serveur de secours par celui du master archivé ci-dessus.

C'est le "running restore : history file not found" qui doit poser problème


Si ça peut t'aider moi j'ai un log shipping qui marche, le standby.log contient par exemple :

Citation:

---

WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
running restore : success

Trigger file : /home/postgres/stoprestore.file
Waiting for WAL file : /datas/pglogs/shipped_logs//000000010000000000000008
WAL file path : 000000010000000000000008
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 5 seconds
Max wait interval : 0 forever
Command for restore : cp "/datas/pglogs/shipped_logs//000000010000000000000008" "pg_xlog/RECOVERYXLOG"
Num archived files kept : last 255 files
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...

---

Et mon recovery.conf :

Citation:

---

restore_command='/apps/pgsql/8.2.5/bin/pg_standby -d -k 255 -t /home/postgres/stoprestore.file /datas/pglogs/shipped_logs/ %f %p 2>> /logs/pgsql/pg_standby.log'

---

Pour initialiser la base de secours ce que tu as fait a l'air OK pourtant

Merci pour la restore_command mais malheureusement, elle ne fonctionne pas, le -k n'est pas reconnu dans les options (peut être lié au fait que je tourne sous 8.2?). Quelle archive_command utilisez-vous sur le serveur master?

Après quelques modifications, j'obtiens ceci :

Citation:

---

Trigger file : /tmp/standby.trigger
Waiting for WAL file : /usr/local/pgsql/data/pg_xlog//00000003.history
WAL file path : 00000003.history
Restoring to... : pg_xlog/RECOVERYHISTORY
Sleep interval : 60 seconds
Max wait interval : 300 seconds
Command for restore : mv /usr/local/pgsql/data/pg_xlog//00000003.history pg_xlog/RECOVERYHISTORY
running restore : success

Trigger file : /tmp/standby.trigger
Waiting for WAL file : /usr/local/pgsql/data/pg_xlog//000000030000000000000004
WAL file path : 000000030000000000000004
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 60 seconds
Max wait interval : 300 seconds
Command for restore : mv /usr/local/pgsql/data/pg_xlog//000000030000000000000004 pg_xlog/RECOVERYXLOG
running restore : success

---

Pour arriver à ce résultat :
Dans recovery.conf :

Code:

---

restore_command = '/usr/local/pgsql/bin/pg_standby -s 60 -w 300 -m -d -t /tmp/standby.trigger /usr/local/pgsql/data/pg_xlog/ %f %p 2>> pg_log/standby.log'

---

Dans le postgres.conf du master:

Code:

---

archive_command = 'scp %p postgres@172.16.5.105:/usr/local/pgsql/data/pg_xlog/%f'

---

Par contre, les nouvelles insertions réalisées sur le master ne sont pas répliquées sur l'esclave.

Citation:

---

Envoyé par Empty_body

Par contre, les nouvelles insertions réalisées sur le master ne sont pas répliquées sur l'esclave.

---

Après tes insertions sur la base maître, est-ce que le dernier WAL est bien transféré et rejoué sur la base esclave avant que tu actives cette dernière ?
Essaie de lancer un

Code:

---

select pg_switch_xlog();

---

sur ta base maître pour forcer la rotation du WAL et son transfert sur la base de secours, ainsi tu seras sûr que tes dernières insertions auront bien été rejouées

Bonjour et merci pour les réponses.

Malheureusement, ça ne fonctionne toujours pas et je voir réapparaitre le message mentionnant l'absence d'un fichier history.

Pour (peut être) aider à débloquer la situation, je vais exposer ce que j'ai fait jusqu'à maintenant...

- Etablissement d'une connexion ssh sécurisée sans mot de passe entre les 2 serveurs.
- Installation de postgres et de pg_standby sur les 2 machines (RHEL5 - Postgres 8.2.7).
- Création d'une base de données sur le master.
- Archivage de la base de données du master gràce aux commades suivantes :

Code:

---

1 2 3

psql template1 -U postgres -c "SELECT pg_start_backup('sauve_1')" tar cvfj pgdata.tar.bz2 /usr/local/pgsql/data psql template1 -U postgres -c "SELECT pg_stop_backup()"

---

- Mise en place du contenu généré au point précédent sur le serveur esclave (décompression du répertoire data du master sur le slave)
- Mise en place d'un recovery.conf sur le serveur slave (repris du répertoire share de postgres et avec pour seule modification la ligne restore_command)

Code:

---

restore_command='/usr/local/pgsql/bin/pg_standby -d -s 30 -w 0 -d -t /tmp/standby.trigger /var/pg_xlog_archives/ %f %p 2>> pg_log/standby.log'

---

A ce stade, je peux couper la restauration et constater le bon fonctionnement du serveur esclave.
- Modification de l'archive_command et de l'archive_timeout sur le serveur master (la commande devient un envoi scp par l'utilisateur postgres et le timeout passe à 5 minutes)

Code:

---

1 2	archive_command = 'scp %p postgres@172.16.5.105:/var/pg_xlog_archives/%f' archive_timeout = 5

---

- Rennomage du recovery.done en recovery.conf et relance du service postgres du slave et du master.
- Insertion de données sur le master et après 30 minutes de patience, modification du fichier trigger sur le serveur esclave pour quitter le mode recovery.
Les problèmes rencontrés sont :
- au bout d'un laps de temps, malgré le transfert des WAL du master vers le slave, le fichier recovery.conf se renomme en recovery.done.
- à intervalle régulier, j'ai un message me signalant qu'un fichier history n'est pas trouvé
- les modifications sur le master ne sont pas répercutées sur le slave.
Je me pose les questions suivantes:
- Aurais-je dû supprimer un / des répertoires sur le serveur de tests? (J'ai tenté de recréer un pg_xlog vide mais ça ne fonctionne pas.)
- Quelle version de Postgres utilisez-vous pour que ça fonctionne?

Gasp... J'obtiens les même logs que ceux que vous avez affiché plus haut et il y a un suivi logique dans les logs... Mais le pépin est que mon serveur master génère un wal 31 par exemple, l'envoie à l'esclave et ce dernier le traite. Après avoir noté successful, l'esclave tente immédiatement une reprise du wal 32. A ce moment, je crée le fichier trigger et la restauration se stoppe. Dans le fichier de log de postgres, je vois que le fichier wal 32 n'a pas pu être restauré et qu'il est manquant, postgres se coupe et refuse de redémarrer... Comment résoudre ce problème???
Lorsque je suis en mode restore, les logs contiennent :
côté "postgres"

Citation:

---

[ 2008-08-08 08:24:01.041 CEST :] LOG: restored log file "0000000100000004000000C1" from archive
[ 2008-08-08 08:25:01.157 CEST :] LOG: restored log file "0000000100000004000000C2" from archive
[ 2008-08-08 08:26:01.649 CEST :] LOG: restored log file "0000000100000004000000C3" from archive

---

Côté standby

Citation:

---

Trigger file : /tmp/standby.trigger
Waiting for WAL file : /var/pg_xlog_archives//0000000100000004000000C2
WAL file path : 0000000100000004000000C2
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 30 seconds
Max wait interval : 0 forever
Command for restore : cp /var/pg_xlog_archives//0000000100000004000000C2 pg_xlog/RECOVERYXLOG
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...
running restore : success

Trigger file : /tmp/standby.trigger
Waiting for WAL file : /var/pg_xlog_archives//0000000100000004000000C3
WAL file path : 0000000100000004000000C3
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 30 seconds
Max wait interval : 0 forever
Command for restore : cp /var/pg_xlog_archives//0000000100000004000000C3 pg_xlog/RECOVERYXLOG
WAL file not present yet. Check for trigger file...

---

Lorsque je quitte le mode restore:
côté standby :

Citation:

---

Trigger file : /tmp/standby.trigger
Waiting for WAL file : /var/pg_xlog_archives//0000000100000004000000C4
WAL file path : 0000000100000004000000C4
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 30 seconds
Max wait interval : 0 forever
Command for restore : cp /var/pg_xlog_archives//0000000100000004000000C4 pg_xlog/RECOVERYXLOG
WAL file not present yet. Check for trigger file...
WAL file not present yet. Check for trigger file...found
trigger file found

---

Côté "postgres" :

Citation:

---

[ 2008-08-08 08:26:01.649 CEST :] LOG: restored log file "0000000100000004000000C3" from archive
[ 2008-08-08 08:27:01.695 CEST :] LOG: could not open file "pg_xlog/0000000100000004000000C4" (log file 4, segment 196): No such file or directory
[ 2008-08-08 08:27:01.695 CEST :] LOG: redo done at 4/C3000068
[ 2008-08-08 08:27:01.700 CEST :] PANIC: could not open file "pg_xlog/0000000100000004000000C3" (log file 4, segment 195): No such file or directory
[ 2008-08-08 08:27:01.701 CEST :] LOG: startup process (PID 31912) was terminated by signal 6
[ 2008-08-08 08:27:01.701 CEST :] LOG: aborting startup due to startup process failure
[ 2008-08-08 08:27:01.760 CEST :] LOG: logger shutting down

---

Je constate par ailleurs que le fichier recovery.conf ne se renomme plus en recovery.done.

Salut a tous,
j'ai suivi cette conversation et j'ai une question.
Avec ma 8.2...ou puis-je recuperer le binaire pg_standby ?
QQ'un sait ou je peux chopper le .c ?
D'avance merci

Sur la page officielle de la contrib :
http://anoncvs.postgresql.org/cvsweb...rib/pg_standby.

Ok merci
ca marche bien