IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Extensions PostgreSQL Discussion :

pg_standby - wall shipping


Sujet :

Extensions PostgreSQL

  1. #1
    Membre actif Avatar de Empty_body
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    681
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2004
    Messages : 681
    Points : 239
    Points
    239
    Par défaut 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.
    Pourquoi vouloir ré-inventer la roue...
    ...Surtout si c'est pour la faire carrée...

  2. #2
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    Qu'as-tu dans le fichier de log du serveur postgresql ?
    Comment as-tu copié la base de secours avant de lancer la synchronisation ?
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  3. #3
    Membre actif Avatar de Empty_body
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    681
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2004
    Messages : 681
    Points : 239
    Points
    239
    Par défaut
    Salut,

    J'ai modifié mon archive_command et le log de postgres me dit ceci :
    [ 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 :
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.
    Pourquoi vouloir ré-inventer la roue...
    ...Surtout si c'est pour la faire carrée...

  4. #4
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    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 :
    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 :
    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
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  5. #5
    Membre actif Avatar de Empty_body
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    681
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2004
    Messages : 681
    Points : 239
    Points
    239
    Par défaut
    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?
    Pourquoi vouloir ré-inventer la roue...
    ...Surtout si c'est pour la faire carrée...

  6. #6
    Membre actif Avatar de Empty_body
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    681
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2004
    Messages : 681
    Points : 239
    Points
    239
    Par défaut
    Après quelques modifications, j'obtiens ceci :

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.
    Pourquoi vouloir ré-inventer la roue...
    ...Surtout si c'est pour la faire carrée...

  7. #7
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    Citation Envoyé par Empty_body Voir le message
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  8. #8
    Membre actif Avatar de Empty_body
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    681
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2004
    Messages : 681
    Points : 239
    Points
    239
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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?
    Pourquoi vouloir ré-inventer la roue...
    ...Surtout si c'est pour la faire carrée...

  9. #9
    Membre actif Avatar de Empty_body
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    681
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2004
    Messages : 681
    Points : 239
    Points
    239
    Par défaut
    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"
    [ 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
    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 :
    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" :
    [ 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.
    Pourquoi vouloir ré-inventer la roue...
    ...Surtout si c'est pour la faire carrée...

  10. #10
    Membre actif
    Inscrit en
    Avril 2006
    Messages
    702
    Détails du profil
    Informations forums :
    Inscription : Avril 2006
    Messages : 702
    Points : 289
    Points
    289
    Par défaut pg_standby
    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

  11. #11
    Membre expérimenté Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Points : 1 734
    Points
    1 734
    Par défaut
    Sur la page officielle de la contrib :
    http://anoncvs.postgresql.org/cvsweb...rib/pg_standby.
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  12. #12
    Membre actif
    Inscrit en
    Avril 2006
    Messages
    702
    Détails du profil
    Informations forums :
    Inscription : Avril 2006
    Messages : 702
    Points : 289
    Points
    289
    Par défaut pg_standby
    Ok merci
    ca marche bien

Discussions similaires

  1. [SQL2005] Log shipping avec 2 serveurs distants
    Par TThieuMa dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 07/12/2007, 21h53
  2. LOG SHIPPING sous SQLSERVER2000
    Par agdid04 dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 03/12/2007, 14h34
  3. LOG SHIPPING MANUEL
    Par tomttf dans le forum MS SQL Server
    Réponses: 6
    Dernier message: 08/11/2007, 10h29
  4. tables temporaire et Log shipping
    Par foblar dans le forum MS SQL Server
    Réponses: 5
    Dernier message: 12/07/2006, 10h25
  5. infos sur le log shipping sans authentification windows
    Par PhilZZR12 dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 13/06/2006, 11h26

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo