Vous n'êtes pas identifié(e).
Bonjour,
quelques soucis de comprehension du concept de logShiping.
Tout d'abord, j'ai lu et utilisé la doc dispo ici: http://dalibo.org/_media/articles/logsh … pg-standby
j'ai donc suivi les instructions.
MASTER:
postgres.conf secction archive:
# - Archiving -
archive_mode = on # allows archiving to be done
# (change requires restart)
#archive_command = '/usr/bin/copyWAL.sh %p %f' # command to use to archive a logfile segment
archive_command = 'scp %p postgres@dcns02:/var/lib/pgsql/data/pg_xlog/%f'
archive_timeout = 60 # force a logfile segment switch after this
# time; 0 is off
les fichiers arrivent parfaitement sur l'autre server..de ce coté pas de problemes...
SLAVE:
fichiers recevery.conf secction restoer command:
restore_command = '/usr/bin/pg_standby -d -k 255 -r 2 -s 2 -w 0 -t/tmp/pgsql.trigger.5422 /var/lib/pgsql/data/pg_xlog %f %p 2 >> /tmp/standby.log'
le resultat souhaité c'est d'avoir la base SLAVE en mode recevery tout le temp...en attente des WAL.
question 1: la base SLAVE doit avoir le mode archive sur on?
question 2: j'ai pas bien compris le role des fichiers: 00000002.history et /tmp/pgsql_trigger.5422
Ce que j'ai fait:
suivre les pas decris ici:
# sauvegarde de base sur le serveur maître
* psql -c "select pg_start_backup('debut')"
* tar cvfj data_maitre.tar.bz2 $PGDATA
* psql -c "select pg_stop_backup()"
* scp data_maitre.tar.bz2 postgres@cible:~/
# restauration de la sauvegarde de base sur le serveur cible
* test -d data && mv data data.old
* tar xvfj data_maitre.tar.bz2
# configuration de la récupération en attente du serveur cible ($PGDATA/recovery.conf)
* restore_command = 'pg_standby -d -k 255 -r 2 -s 2 -w 0 \ -t /tmp/pgsql.trigger.5442 /var/pg_xlog_archives %f %p 2>> standby.log'
ensuite lorsque je demarre la base SLAVE j'ai ceci dans les log:
5721 pts/2 S 0:00 /usr/bin/postgres -D /var/lib/pgsql/data/
5722 ? Ss 0:00 postgres: logger process
5741 ? Ss 0:00 postgres: writer process
5742 ? Ss 0:00 postgres: wal writer process
5743 ? Ss 0:00 postgres: autovacuum launcher process
5744 ? Ss 0:00 postgres: archiver process failed on 00000002.history
5746 ? Ss 0:00 postgres: stats collector process
25327 pts/0 Ss+ 0:00 -bash
-bash-3.2$ tail -f postgresql-2009-02-13_115644.log
DETAIL: The failed archive command was: scp pg_xlog/00000002.history postgres@dcns02:/var/lib/pgsql/data/pg_xlog/00000002.history
Host key verification failed.
lost connection
LOG: archive command failed with exit code 1
DETAIL: The failed archive command was: scp pg_xlog/00000002.history postgres@dcns02:/var/lib/pgsql/data/pg_xlog/00000002.history
Host key verification failed.
lost connection
LOG: archive command failed with exit code 1
DETAIL: The failed archive command was: scp pg_xlog/00000002.history postgres@dcns02:/var/lib/pgsql/data/pg_xlog/00000002.history
WARNING: transaction log file "00000002.history" could not be archived: too many failures
a quel moment je dois faire le touch du trigger dans tmp?? au debut...avant de lancer la base SLAVE?
Merci de m'eclairer.
Ciao
Hors ligne
j'ai refais les manips...
maintenant j'ai ceci dans le log de la base SLAVE:
Trigger file : /tmp/pgsql.trigger.5422
Waiting for WAL file : 00000004000000000000000F
WAL file path : /var/lib/pgsql/data/pg_xlog/00000004000000000000000F
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 2 seconds
Max wait interval : 0 forever
Command for restore : cp "/var/lib/pgsql/data/pg_xlog/00000004000000000000000F" "pg_xlog/RECOVERYXLOG"
Keep archive history : No cleanup required
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...
il a bien recuperé le WAL que SOURCE avait envoyé
mais lorsque la base SOURCE a envoyé un second, la base TARGET n'a rien fait...
Hors ligne
Rassure-moi, tu ne copies pas les journaux de transactions directement dans le répertoire pg_xlog du serveur distant ?
Pour répondre à tes autres questions :
question 1: la base SLAVE doit avoir le mode archive sur on?
Elle peut mais ce n'est pas nécessaire. En tout cas, il faut évidemment éviter que la commande d'archivage copie dans le même répertoire.
question 2: j'ai pas bien compris le role des fichiers: 00000002.history et /tmp/pgsql_trigger.5422
Ce fichier permet de stopper la restauration. Donc il ne faut pas l'utiliser tant que le maître fonctionne bien.
Guillaume.
Hors ligne
avant oui
maintenant (en lisant quelques doc) j'ai cré un autre repoertoire et les fichiers arrivent maitenant dans $PGDATA/srv1_wals
Pour letrigger...
ok donc il faut creer ce fichier lorsque l'on veut arreter la restoration...
mais si le log du slave dit toujours ceci:
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
bien que de nouveau fichiers arrivent..ca veut dire que y'a un parametre qui coince n'est ce pas?
Ca peu etre pg_standby qui esta mal compilé ou quelques chose comme ca?
MSN: ldiaz@hotmail.fr (si tu preferes)
Hors ligne
Ok ca marche.....
cette fois j'ai compris le role du fichier trigger.
EN fait pg_standby jette un oeil voir s'il existe...s¡il existe il s'arrete
et sinon il continu a restorer..
Alors 'ai une derniere querstion:
si je veux faire un rotate des fichiers wall qui arrivent sur le server slave? c'est possible? y'a un parametre de pg_standby qui fait ca?
Je vais lire la doc
si je trouve je placerais la reponse ici
D'avance merci
Hors ligne
Un rotate non mais ce n'est pas nécessaire car il existe une option pour supprimer les anciens journaux. L'option est -k et précise le nombre de journaux à conserver. S'il en existe plus, il supprimera les plus anciens.
Guillaume.
Hors ligne
Ok merci encore pout ton aide
A bientot
Ciao
Hors ligne
Bonjour a tous.
juste un doute, j'ai lu que l'option -k (et un numero) de pg_standby qui sert a faire un rotate des WAL...est obso...
C'est vrai ca?
j'ai essayé de l'utiliser mais ca ne marche pas...les WALs qui arrivent sur le server slave restent tous, sans qu'aucin ne s'efface.
J'au aussi lu que on peu utiliser l'option %r
Vous en pensez quoi?
D'avance merci
Hors ligne
Bonjour a tous
avec cette ligne dans le fichier recovery.conf du slave, la replication ne marche pas.
restore_command = '/usr/bin/pg_standby -d -t /tmp/stoprestore.file /var/lib/pgsql/dcns01_wals/ %f %p %r 2>> /var/lib/pgsql/data/pg_log/reco.log'
les wals arrivent bien mais rien ne se passe
le log reste comme ca:
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...
Hors ligne
C'est vrai, il est obsolète. Il devrait cependant fonctionner. Si tu as mis 100 après l'option -l, tu conserveras en permanence 100 journaux sur le disque. Dès qu'un 101è arrive, le plus ancien est supprimé. Donc tu ne l'as peut-être pas assez laissé tourner pour voir si cela fonctionnait.
L'option %r est par contre plus intéressante car il ne supprimera que ceux dont le serveur PostgreSQL n'a réellement plus besoin. Si tu es en 8.3, tu as beaucoup plus intérêt à utiliser cette option.
Guillaume.
Hors ligne
Oui c'est la version 8.3...
Ben tu sais, j'ai mis le %r, mais rien ne marche,....ca replique plus.
T'as une idée de ce qui pourrait deconner?
je te colle ici les files: postgres.conf du master et le recover.con du slave
postgres.conf
# - Checkpoints -
#checkpoint_segments = 3 # in logfile segments, min 1, 16MB each
checkpoint_timeout = 1min # range 30s-1h
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
#checkpoint_warning = 30s # 0 is off
# - Archiving -
archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = 'scp %p postgres@dcns02:/var/lib/pgsql/dcns01_wals/%f' # command to use to archive a logfile segment
archive_timeout = 300 # force a logfile segment switch after this
# time; 0 is off
recovery.conf du slave
restore_command = '/usr/bin/pg_standby -d -t /tmp/stoprestore.file /var/lib/pgsql/dcns01_wals/ %f %p %r 2>> /var/lib/pgsql/data/pg_log/reco.log'
D'avance merci
Hors ligne
Difficile de dire comme ça. Tu as des messages d'erreur ? que se passe-t'il ? les journaux arrivent-ils bien sur le secondaire ? ne sont-ils pas découverts par pgstandby ?
Guillaume.
Hors ligne
Oui les WAL arrivent bien sur le server SLAVE, mais si tu regarde le LOG, ya' rien, il dit juste ca:
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
mais pourtant les walls arrivent.
Y'a pas de messages d'erreurs dans les log.
Curieux non?
ca pourrait venir du pg_standby? mal compilé ou qq chose comme ca?
Hors ligne
Non, ça m'étonnerait. Il cherche quel fichier WAL ? est-t-il présent sur le serveur en standby ?
Guillaume.
Hors ligne
Lorsque tu dis: est il present?? tu fais refetrence au fichier wal??
alors je te file plus de details:
1 le server master a le mode archive activé, il envoie via scp les wals vers un repertoire qui se trouve ici: /var/lib/pgsql/dcns01_wals/
ca marche bien...tout les n minutes le server 1 envoie les wal verde server 2
2 le server 2 est en mode standby, avec le fichier recovery.conf (pas .done)
avec ce parametre: restore_command = '/usr/bin/pg_standby -d -t /tmp/stoprestore.file /var/lib/pgsql/dcns01_wals/ %f %p %r 2>> /var/lib/pgsql/data/pg_log/reco.log'
dans le fichier reco.log tu as ceci:
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 lorsqu'un nouveau fichier arrive il ne le traite pas..
Ca ressemble a qu'il est en trai d'attendre un fichier qui ne lui arrive pas....
peut etre attend t'il un 0000000000000001 et comme les wals maintenant on des numeros diferrents..
Tu crois que je pourrais renommer un des wals sur le server slave voir s'il le charge et se debloque?
Hors ligne
Non, surtout pas. Les logs de pgstandby doivent t'indiquer le WAL qu'il cherche. Est-il présent dans /var/lib/pgsql/dcns01_wals ? quel est le fichier qu'il cherche et quells sont les fichiers présents dans le répertoire /var/lib/pgsql/dcns01_wals ?
Guillaume.
Hors ligne
mmmm
le log dont tu parle c'est celui que je cré avec cette commande?
restore_command = '/usr/bin/pg_standby -d -t /tmp/stoprestore.file /var/lib/pgsql/dcns01_wals/ %f %p %r 2>> /var/lib/pgsql/data/pg_log/reco.log'
donc reco.log ??
ou existe t'il un autre log?
pour le moment j'ai ceci dans le log:
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...trigger file found
ERROR: could not remove "/tmp/stoprestore.file": Operation not permitted
Trigger file : /tmp/stoprestore.file
Waiting for WAL file : 00000004.history
WAL file path : /var/lib/pgsql/dcns01_wals//00000004.history
Restoring to... : pg_xlog/RECOVERYHISTORY
Sleep interval : 5 seconds
Max wait interval : 0 forever
Command for restore : cp "/var/lib/pgsql/dcns01_wals//00000004.history" "pg_xlog/RECOVERYHISTORY"
Keep archive history : 000000000000000000000000 and later
running restore :cp: cannot stat `/var/lib/pgsql/dcns01_wals//00000004.history': No such file or directory
cp: cannot stat `/var/lib/pgsql/dcns01_wals//00000004.history': No such file or directory
cp: cannot stat `/var/lib/pgsql/dcns01_wals//00000004.history': No such file or directory
not restored : history file not found
Trigger file : /tmp/stoprestore.file
Waiting for WAL file : 00000004000000000000001C
WAL file path : /var/lib/pgsql/dcns01_wals//00000004000000000000001C
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 5 seconds
Max wait interval : 0 forever
Command for restore : cp "/var/lib/pgsql/dcns01_wals//00000004000000000000001C" "pg_xlog/RECOVERYXLOG"
Keep archive history : 000000000000000000000000 and later
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...
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 la ca change plus ca reste tel que...
Dans le repertoire /var/lib/pgsql/dcns01_wals j'ai plein de WAL qui proviennent du server master.
drwxr-xr-x 2 postgres postgres 4096 Feb 16 16:44 dcns01_wals
contenu:
-rw------- 1 postgres postgres 16777216 Feb 16 16:14 00000001000000000000006F
-rw------- 1 postgres postgres 16777216 Feb 16 16:19 000000010000000000000070
-rw------- 1 postgres postgres 16777216 Feb 16 16:24 000000010000000000000071
-rw------- 1 postgres postgres 16777216 Feb 16 16:29 000000010000000000000072
-rw------- 1 postgres postgres 16777216 Feb 16 16:34 000000010000000000000073
-rw------- 1 postgres postgres 16777216 Feb 16 16:39 000000010000000000000074
-rw------- 1 postgres postgres 16777216 Feb 16 16:44 000000010000000000000075
-bash-3.2$ ll | wc -l
60
tu vois y'en a 60...
Ca voudrais dire que pg_standby attend un fichier mais qui n'est pas ...ou plus dans ce repoertoire?
Hors ligne
S'il recherche le 00000004000000000000001C alors la oui...il n'est pas dans le server...
tiens regarde j'ai fait un ps ax:
20671 ? Ss 0:00 postgres: logger process
20672 ? Ss 0:00 postgres: startup process waiting for 00000004000000000000001C
20679 ? S 0:00 sh -c /usr/bin/pg_standby -d -t /tmp/stoprestore.file /var/lib/pgsql/dcns01_wals/ 00000004000000000000001C pg_xlog/RECOVERYXLOG 00020680 ? S 0:00 /usr/bin/pg_standby -d -t /tmp/stoprestore.file /var/lib/pgsql/dcns01_wals/ 00000004000000000000001C pg_xlog/RECOVERYXLOG 00000000021611 ? Ss 0:00 sshd: root@pts/2
on dirais qu'il attend apres ce fichier...
Comment je peux faire car ce fichier n'est pas dans le repertoire (j'ai du l'effacer)
Tu crois que je dois recommencer du debut?
Hors ligne
Attends, tu as un message d'erreur et tu ne le dis même pas 
ERROR: could not remove "/tmp/stoprestore.file": Operation not permitted
Autrement dit, il a détecté le fichier trigger donc il a arrêté la restauration mais il n'arrive pas à le supprimer.
Bref, arrête le serveur PostgreSQL en attente (ton secondaire). Supprime le fichier /tmp/stoprestore.file. Et reconstruis ton secondaire.
Le fichier trigger ne doit exister qu'au moment où tu veux arrêter la restauration.
Guillaume.
Hors ligne
Ou llaaaa
non attends, actuellement ce fichier (le trigger) n'ai plus dans /tmp
en fais j'avais fait le touch /tmp/trigger avec l'utilisateur root...
et en voyant l'erreur je l'ai effacé.
Donc la y'a plus le trigger. (j'ai copié une tonne de log, donc ca remonte a ce matin)
D'ailleur il se passe un truc etrange.
Si je cré le trigger avec l'user postgres...
-bash-3.2$ touch /tmp/stoprestore.file
-bash-3.2$ tail -f reco.log
Trigger file : /tmp/stoprestore.file
Waiting for WAL file : 00000004000000000000001C
WAL file path : /var/lib/pgsql/dcns01_wals//00000004000000000000001C
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 5 seconds
Max wait interval : 0 forever
Command for restore : cp "/var/lib/pgsql/dcns01_wals//00000004000000000000001C" "pg_xlog/RECOVERYXLOG"
Keep archive history : 000000000000000000000000 and later
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...
Tu vois il fait le recover et hop au lieu de s'arreter, il continu a attendre les wals.
Hors ligne
Mouais. Moi, je recommencerais l'install du serveur esclave en faisant bien attention à tout supprimer avant, notamment les traces, les fichiers triggers, etc.
Guillaume.
Hors ligne
ok, je recommence le slave
que faire avec le master? je le laisse tel que?
Hors ligne
Alors les dernieres nouvelles,
En refaisant les steps que tu explique (dans ton site web) ca remarche bien.
Cool
Maintenant je voudrait controler 2 choses:
1 la frequence de creation dea WALL du serveur MASTER
2 verifier que l'option %r dans le restore command fonctionne bien.
Pour la question 1, je dois modifier quel parametre entre ces 2 la?
checkpoint_timeout = 1min # range 30s-1h
archive_timeout = 300 # force a logfile segment switch after this
D'avance merci
Hors ligne
Les deux
archive_timeout indique le délai à partir duquel le journal peut être archivé, mais il ne le sera réellement que quand un checkpoint sera survenu. Il convient donc de les bouger ensemble.
Guillaume.
Hors ligne
20672 ? Ss 0:00 postgres: startup process waiting for 00000004000000000000001C
20679 ? S 0:00 sh -c /usr/bin/pg_standby -d -t /tmp/stoprestore.file /var/lib/pgsql/dcns01_wals/ 00000004000000000000001C pg_xlog/RECOVERYXLOG 00020680 ? S 0:00 /usr/bin/pg_standby -d -t /tmp/stoprestore.file /var/lib/pgsql/dcns01_wals/ 00000004000000000000001C pg_xlog/RECOVERYXLOG 00000000021611 ? Ss 0:00 sshd: root@pts/2on dirais qu'il attend apres ce fichier...
Comment je peux faire car ce fichier n'est pas dans le repertoire (j'ai du l'effacer)
Tu crois que je dois recommencer du debut?
Bonjour
Je viens de m'inscrire puisque en ce moment je fais des tests de réplication et après différents essais
j'ai constaté le comportement suivant :
Au début tout fonctionne, nous avons les segments WAL de type 00000001000000000000001C
qui sont bien recopié sur le SLAVE et bien pris en compte
Et nous avons bien le process
sh -c pg_standby -d -t /tmp/stoprestore /var/postgresl/backup_wals/ 00000001000000000000001C
Puis quand on arrête le RECOVERY par le fichier /tmp/stoprestore
Le serveur sur SLAVE devient autonome, la base de donnée devient accessible
Des segments WALL apparaît dans pg_xlog avec pour nom 00000002000000000000001C (Incrémentation du TimeLineID)
Un 2 apparaît à la place du 1
Du coup quand on arrête la base de donnée, on remet recovery.conf et on relance la base de donnée en mode recovery
j'ai le process suivant :
sh -c pg_standby -d -t /tmp/stoprestore /var/postgresl/backup_wals/ 00000002000000000000001C
Le SLAVE ne peut plus synchronisé puisqu'il attend 00000002... alors que le Master continue à envoyer les 00000001...
Remède:
La seule solution que j'ai trouvé est de réinitialiser le SLAVE à chaque fois que l'on veut redémarrer le mode RECOVERY
Si la base est volumineux, on peut utiliser sync -a pour recopier le delta du MASTER vers le SLAVE
Dernière modification par goupil (02/06/2009 15:56:12)
Hors ligne
