Forums PostgreSQL.fr

ldiaz

Membre

PG_STANDBY

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

ldiaz

Membre

Re : PG_STANDBY

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...

gleu

Administrateur

Re : PG_STANDBY

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.

ldiaz

Membre

Re : PG_STANDBY

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)

ldiaz

Membre

Re : PG_STANDBY

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

gleu

Administrateur

Re : PG_STANDBY

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.

ldiaz

Membre

Re : PG_STANDBY

Ok merci encore pout ton aide
A bientot
Ciao

ldiaz

Membre

Re : PG_STANDBY

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

ldiaz

Membre

Re : PG_STANDBY

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...

gleu

Administrateur

Re : PG_STANDBY

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.

ldiaz

Membre

Re : PG_STANDBY

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

gleu

Administrateur

Re : PG_STANDBY

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.

ldiaz

Membre

Re : PG_STANDBY

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?

gleu

Administrateur

Re : PG_STANDBY

Non, ça m'étonnerait. Il cherche quel fichier WAL ? est-t-il présent sur le serveur en standby ?

---

Guillaume.

ldiaz

Membre

Re : PG_STANDBY

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?

gleu

Administrateur

Re : PG_STANDBY

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.

ldiaz

Membre

Re : PG_STANDBY

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?

ldiaz

Membre

Re : PG_STANDBY

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?

gleu

Administrateur

Re : PG_STANDBY

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.

ldiaz

Membre

Re : PG_STANDBY

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.

gleu

Administrateur

Re : PG_STANDBY

Mouais. Moi, je recommencerais l'install du serveur esclave en faisant bien attention à tout supprimer avant, notamment les traces, les fichiers triggers, etc.

---

Guillaume.

ldiaz

Membre

Re : PG_STANDBY

ok, je recommence le slave
que faire avec le master? je le laisse tel que?

ldiaz

Membre

Re : PG_STANDBY

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

gleu

Administrateur

Re : PG_STANDBY

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.

goupil

Membre

Re : PG_STANDBY

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?

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)