Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 23/10/2008 15:26:13
- ldiaz
- Membre
replication
Bonjour a toutes/tous
je suis en train de monter 2 bases postgres: master et slave, dans le but d'utiliser warm standby.
J'ai recupeŕe la doc de Charles duffy. Il est question de ca dans son post mais avec un seul serveur qui fait office de master et slave (il utilise 2 repertoire differents pour les data).
Dans la doc "oficille" il y a ceci:
# Set up continuous archiving from the primary to a WAL archive located in a directory on the standby server. Ensure that archive_command and archive_timeout are set appropriately on the primary (see section 10.3.1 Setting up WAL archiving).
Dans le cas d'un seul serveur, je pige bien, mais dans mon cas avec 2 machines distantes?? je suis obligé de monter une partition NFS sur la machine MASTER y de declarer cet endroit comme receptacle des WAL?
Ou existe t'il une autre façon de faire pour passer les files du server Master au Slave.
Faut il creer un cron synchronisé avec la creation des WAL?
D'avance merci
Luis
Hors ligne
#2 23/10/2008 16:33:51
- gleu
- Administrateur
Re : replication
Pas de cron, c'est PostgreSQL qui exécute la commande quand c'est nécessaire. Cette commande peut être toute commande de copie : cp, scp, rcp, ftp, etc. Voire un script.
Guillaume.
Hors ligne
#3 23/10/2008 16:53:07
- ldiaz
- Membre
Re : replication
Haaa
tu veux dire que ca:
'cp /mnt/server/archivedir/%f %p'
il suffit que je remplace par 'scp' et voila??
Genial
Merci
Hors ligne
#4 23/10/2008 19:49:21
- gleu
- Administrateur
Re : replication
Yep, exactement. Tu trouveras un guide rapide sur http://dalibo.org/installation_du_log_shipping. Si tu as un commentaire sur cette doc, je suis intéressé, vu que je l'ai écrit et que j'aimerais qu'il soit le plus précis possible.
Guillaume.
Hors ligne
#5 27/10/2008 11:28:47
- ldiaz
- Membre
Re : replication
Salut,
t'as doc est super, ca explique pas mal de concept que je ne connaissait pas.
J'ai une question du coup.
Le script pg_standby ne marche que sur 8.3? ou je peux le passer a une platforme maitre esclave en 8.2 que j'ai ?
Ma seconde question (derniere):
Si j'ai bien tout compris, le restore se fait si et seulement si le fichier recovery.conf existe dans $PGDATA
si tu ne passe pas de script special, apres le restore, le fichier recovery.conf est renomé recovery.done.
Dans ce cas t'es plus en mode recovery mais en prod...C'est bien ca?
Dans mon cas, j'ai recuperé ce script qui normalement sert a ca, mais ca marche pas:
#!/bin/bash
RESTORE_FROM=$1
RESTORE_TO=$2
DELAY=100000
TRIGGERED=0
TRIGGER_FILE="/ORA/dbs00/importPostgres/"
copyfunc() {
if [ "$TRIGGERED" -eq "0" ]; then
cp -v -i $RESTORE_FROM $RESTORE_TO
fi
}
k=`expr $1 : '.*\(history\)'`
if [ "$k" == "history" ]; then
copyfunc;
exit $?;
fi
while [ ! -f "$RESTORE_FROM" -a "$TRIGGERED" -eq "0" ]; do
usleep $DELAY;
if [ -e $TRIGGER_FILE ]; then
TRIGGERED=1;
fi
done
copyfunc;
Je pige pas ce script...peu etre avec pg_standby c'est plus facil.
Merci de m'eclairer.
Hors ligne
#6 27/10/2008 11:32:10
- ldiaz
- Membre
Re : replication
Voici quelques details de ma config:
serveur maitre:
archive_command = 'cp -i %p /ORA/dbs00/importPostgres/%f && scp %p oratest02:/usr/local/pgsql/data/pg_xlog </dev/null'
Cette commande marche bien, chaque fois que j'ai un fichier WAL crée, hop il le passe au server slave.
serveur slave:
restore_command = '/usr/local/pgsql/data/restore.sh /usr/local/pgsql/data/pg_xlog/%f "%p"'
Hors ligne
#7 27/10/2008 11:43:48
- ldiaz
- Membre
Re : replication
Ok j'ai vue dans le liens que tu donne dans le PDF.
je peux utiliser pg_standby avec la 8.2 cool
Hors ligne
#8 27/10/2008 11:55:34
- gleu
- Administrateur
Re : replication
Exact, on peut utiliser pg_standby avec la 8.2. Je l'ai déjà fait chez des clients, je n'ai eu aucun soucis.
Si j'ai bien tout compris, le restore se fait si et seulement si le fichier recovery.conf existe dans $PGDATA
Exact.
si tu ne passe pas de script special, apres le restore, le fichier recovery.conf est renomé recovery.done.
Dans ce cas t'es plus en mode recovery mais en prod...C'est bien ca?
Une fois la restauration terminée, le fichier recovery.conf est renommé pour qu'au prochain arrêt/démarrage du serveur, PostgreSQL ne pense pas être en mode restauration.
Une fois la restauration terminée, tu es en prod, le serveur attend les connexions.
Concernant ton script, aucune idée, mais utilise pg_standby, c'est fait pour ça.
Guillaume.
Hors ligne
#9 27/10/2008 12:01:49
- ldiaz
- Membre
Re : replication
Salut,
tu sais ou je peux recupere pg_standby?? c'est un .c que je devrait compiler?
J'ai regardé dans le bin de PGGOME et y'a pas....
D'avance merci
Hors ligne
#10 27/10/2008 12:55:50
- gleu
- Administrateur
Re : replication
Il faut récupérer les sources avec la 8.3, il se trouve dans les modules contrib.
Guillaume.
Hors ligne
#11 27/10/2008 14:08:31
- ldiaz
- Membre
Re : replication
Ok, merci pour tout,
je vais tester ca.
Ciao
Hors ligne
#12 27/10/2008 18:11:07
- ldiaz
- Membre
Re : replication
Salut de nouveau,
alors voila, j'ai appliqué (surement de travers) les instructions du PDF.
J'ai un serveur MASTER qui genere les WAL et les envoie via scp a l'autre serveur.
Ca, ca marche bien...
MASTER:
archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = 'scp %p postgres@oratest02:/usr/local/pgsql/data/pg_xlog/%f' # command to use to archive a logfile segment
archive_timeout = 60
SLAVE:
[postgres@oratest02 data]$ cd pg_xlog/
[postgres@oratest02 pg_xlog]$ ll
total 32812
-rw------- 1 postgres postgres 16777216 Oct 27 16:50 000000010000000000000000
drwx------ 2 postgres postgres 4096 Oct 27 16:19 archive_status
-rw------- 1 postgres postgres 16777216 Oct 27 17:04 RECOVERYXLOG
Mais lorsque je demarre le SLAVE, j'ai ceci:
LOG: database system was shut down at 2008-10-27 16:31:30 CET
LOG: starting archive recovery
LOG: restore_command = '/usr/local/pgsql/bin/pg_standby -d -r 2 -s 2 -t/tmp/pgsql.trigger.5422 /usr/local/pgsql/data/pg_xlog %f %p 2 >> /tmp/standby.log'
Trigger file : /tmp/pgsql.trigger.5422
Waiting for WAL file : 00000001.history
WAL file path : /usr/local/pgsql/data/pg_xlog/00000001.history
Restoring to... : pg_xlog/RECOVERYHISTORY
Sleep interval : 2 seconds
Max wait interval : 0 forever
Command for restore : cp "/usr/local/pgsql/data/pg_xlog/00000001.history" "pg_xlog/RECOVERYHISTORY"
Keep archive history : No cleanup required
running restore :cp: cannot stat `/usr/local/pgsql/data/pg_xlog/00000001.history': No such file or directory
cp: cannot stat `/usr/local/pgsql/data/pg_xlog/00000001.history': No such file or directory
not restored : history file not found
Trigger file : /tmp/pgsql.trigger.5422
Waiting for WAL file : 000000010000000000000000
WAL file path : /usr/local/pgsql/data/pg_xlog/000000010000000000000000
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 2 seconds
Max wait interval : 0 forever
Command for restore : cp "/usr/local/pgsql/data/pg_xlog/000000010000000000000000" "pg_xlog/RECOVERYXLOG"
Keep archive history : No cleanup required
running restore : OKLOG: restored log file "000000010000000000000000" from archive
LOG: invalid record length at 0/9C0E80
LOG: invalid primary checkpoint record
Trigger file : /tmp/pgsql.trigger.5422
Waiting for WAL file : 000000010000000000000000
WAL file path : /usr/local/pgsql/data/pg_xlog/000000010000000000000000
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 2 seconds
Max wait interval : 0 forever
Command for restore : cp "/usr/local/pgsql/data/pg_xlog/000000010000000000000000" "pg_xlog/RECOVERYXLOG"
Keep archive history : No cleanup required
running restore : OKLOG: restored log file "000000010000000000000000" from archive
LOG: invalid resource manager ID in secondary checkpoint record
PANIC: could not locate a valid checkpoint record
LOG: startup process (PID 20449) was terminated by signal 6: Aborted
LOG: aborting startup due to startup process failure
Il cherche au debut un fichier qui n'existe pas:
running restore :cp: cannot stat `/usr/local/pgsql/data/pg_xlog/00000001.history': No such file or directory
par contre pour le second on dirait qu'il se passe qque chose, vu qu'il cré ceci:
-rw------- 1 postgres postgres 16777216 Oct 27 17:04 RECOVERYXLOG
bref, je suis paumé
Un peu d'aide?
Hors ligne
#13 27/10/2008 18:27:52
- ldiaz
- Membre
Re : replication
attends, j'ai revisé de script, j'avais pas fait le tar de data entre le pg_start_backup et stop backup....
je l'ai refais comme ca et maintenant j'ai 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...
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...
mieux
dans 4 mn y'a un WAL qui arrive il devrait le charger n'est ce pas ??
Hors ligne
#14 27/10/2008 18:40:13
- ldiaz
- Membre
Re : replication
Regarde ce qui se passe, j'ai voulu arreter le recovery comme tu indique dans le PDF en faisant le touche... dans /tnp
ca a declenché 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...trigger file found
Trigger file : /tmp/pgsql.trigger.5422
Waiting for WAL file : 000000010000000000000004
WAL file path : /usr/local/pgsql/data/pg_xlog/000000010000000000000004
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 2 seconds
Max wait interval : 0 forever
Command for restore : cp "/usr/local/pgsql/data/pg_xlog/000000010000000000000004" "pg_xlog/RECOVERYXLOG"
Keep archive history : No cleanup required
running restore : OKLOG: restored log file "000000010000000000000004" from archive
LOG: automatic recovery in progress
LOG: redo starts at 0/4000068
Trigger file : /tmp/pgsql.trigger.5422
Waiting for WAL file : 000000010000000000000005
WAL file path : /usr/local/pgsql/data/pg_xlog/000000010000000000000005
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 2 seconds
Max wait interval : 0 forever
Command for restore : cp "/usr/local/pgsql/data/pg_xlog/000000010000000000000005" "pg_xlog/RECOVERYXLOG"
Keep archive history : No cleanup required
running restore : OKLOG: restored log file "000000010000000000000005" from archive
Trigger file : /tmp/pgsql.trigger.5422
Waiting for WAL file : 000000010000000000000006
WAL file path : /usr/local/pgsql/data/pg_xlog/000000010000000000000006
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 2 seconds
Max wait interval : 0 forever
Command for restore : cp "/usr/local/pgsql/data/pg_xlog/000000010000000000000006" "pg_xlog/RECOVERYXLOG"
Keep archive history : No cleanup required
running restore : OKLOG: restored log file "000000010000000000000006" from archive
Trigger file : /tmp/pgsql.trigger.5422
Waiting for WAL file : 000000010000000000000007
WAL file path : /usr/local/pgsql/data/pg_xlog/000000010000000000000007
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 2 seconds
Max wait interval : 0 forever
Command for restore : cp "/usr/local/pgsql/data/pg_xlog/000000010000000000000007" "pg_xlog/RECOVERYXLOG"
Keep archive history : No cleanup required
running restore : OKLOG: restored log file "000000010000000000000007" from archive
Trigger file : /tmp/pgsql.trigger.5422
Waiting for WAL file : 000000010000000000000008
WAL file path : /usr/local/pgsql/data/pg_xlog/000000010000000000000008
Restoring to... : pg_xlog/RECOVERYXLOG
Sleep interval : 2 seconds
Max wait interval : 0 forever
Command for restore : cp "/usr/local/pgsql/data/pg_xlog/000000010000000000000008" "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...
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
Tu vois, postgres SLAVE a restauré tous les WAL qui etaient present....
Etrange non?
Hors ligne
#15 27/10/2008 18:58:07
- gleu
- Administrateur
Re : replication
Il cherche au debut un fichier qui n'existe pas:
running restore :cp: cannot stat `/usr/local/pgsql/data/pg_xlog/00000001.history': No such file or directory
Logique, ce fichier n'existe jamais. Le premier sera créé lors du changement de timeline et aura pour nom 00000002.history.
mieux
dans 4 mn y'a un WAL qui arrive il devrait le charger n'est ce pas ??
Exact.
Tu vois, postgres SLAVE a restauré tous les WAL qui etaient present....
Etrange non?
Ce qui est étrange, c'est qu'il détecte bien le fichier mais ne s'arrête pas. Je ne comrpends pas bien pourquoi.
Guillaume.
Hors ligne
#16 27/10/2008 19:04:33
- gleu
- Administrateur
Re : replication
Ce qui m'étonne aussi, c'est que tu as des logs de PostgreSQL (par exemple, LOG: automatic recovery in progress et LOG: redo starts at 0/4000068) et des logs de pg_standby. Ils sont enregistrés dans le même fichier ?
Guillaume.
Hors ligne
#17 29/10/2008 15:34:04
- ldiaz
- Membre
Re : replication
oui les logs arrivent dans le meme fichier...
Bon je sais pas, je suis debutant,,,donc.
Une petite question maintenant que ca marche mortel bien:
Est il possible d'avoir une quantité limitée de fichiers WAL dans le $PGDATA/pg_xlog du MASTER?
Genre un rotate?
Hors ligne
#18 29/10/2008 15:58:08
- gleu
- Administrateur
Re : replication
Il y a toujours un rotate des fichiers de pg_xlog.Tu as en temps normal un maximum de (2 + checkpoint_completion_target) * checkpoint_segments + 1 fichiers. Tu peux avoir des poussés à 3 * checkpoint_segments mais c'est généralement rare. Sauf dans le cas où l'archivage (PITR) est activé et que la commande d'archivage échoue...
Guillaume.
Hors ligne
#19 29/10/2008 16:22:59
- ldiaz
- Membre
Re : replication
Et y'a rien a configurer pour obtenir ca?
C'est par default?
En tout cas, dans le serveur slave, il y a pleins de WAL, ...pas de rotate.
C'est normal? ou je dois configurer qque chose pour que le rotate se fasse?
Hors ligne
#20 29/10/2008 16:34:55
- gleu
- Administrateur
Re : replication
Et y'a rien a configurer pour obtenir ca?
En dehors de checkpoint_segments pour indiquer combien tu en veux au maximum, non.
C'est par default?
Oui. Quelque soit la version utilisée.
En tout cas, dans le serveur slave, il y a pleins de WAL, ...pas de rotate.
C'est normal? ou je dois configurer qque chose pour que le rotate se fasse?
C'est différent. Ce n'est pas PostgreSQL qui gère le répertoire où sont copiés les WAL par la commande archive_command. C'est du coup de la responsabilité de l'administrateur.
Guillaume.
Hors ligne
#21 30/10/2008 18:09:15
- ldiaz
- Membre
Re : replication
Ok Super,
cette fois je l'ai clair...
Bon c'est pas mal tout ca.
merci pour tout
A bientot sur le forum
Ciao
Hors ligne
#22 13/02/2009 12:06:03
- ldiaz
- Membre
Re : replication
Re bonjour Guillaume...
je reviens avec ce théme de postgres...
J'espere que t'es encore dans les parages...
J'ai remonté la meme install sur 2 aures machines...et ca marche pas super.
Regarde j'ai 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...
WAL file not present yet. Checking for trigger file...
donc la ca veut dire que le server slave attend un WAL...
le probleme c'est que les WAL arrivent bien,mais rien ne se declenche.
J'ai pas bien compris l'histoire du fichier trigger...
tu sais celui ci:
WAL file not present yet. Checking for trigger file...trigger file found
Trigger file : /tmp/pgsql.trigger.5422
Je le cré au debut...
mais ensuite il disparait et plus rien ne se passe.
Merci de m'eclairer.
Ciao
Hors ligne
#23 13/02/2009 12:19:45
- gleu
- Administrateur
Re : replication
Difficile de t'aider sans plus d'infos. Il faudrait au moins fournir l'archive_command, le restore_command, etc. Je pense aussi qu'il faudrait mieux créer une nouvelle discussion plutôt que de revenir à chaque fois à l'ancienne.
Guillaume.
Hors ligne
#24 13/02/2009 12:47:14
- ldiaz
- Membre
Re : replication
ok
je cré la nouvelle avec les details.
Merci
Hors ligne
Pages : 1