Vous n'êtes pas identifié(e).
Pages : 1
Bonjour ,
Je viens de débuter avec postgresql, et j"ai un problème.
J'ai 4 machines sur lesquels j'ai installer Debian wheezy 7.1 , sur chaque une de ces machines j'ai installer des vm avec xen.
1 ere machine : j'ai installer pgpool dessus
2 eme machine : j'ai installer postgresql et c'est le serveur maitre
3eme machine : j'ai installer postgresql et c'est le serveur standby1
4eme machine : j'ai installer postgresql et c'est le serveur standby2
j'ai mis en place la réplication ça marche nickel, quand je fait un : ps -u postgres u
postgres 421 0.0 0.0 19484 1616 pts/0 S juil.09 0:00 -su
postgres 474 0.0 0.0 74772 2532 pts/0 S+ juil.09 0:00 /usr/lib/postgresql/9.1/bin/psql
postgres 11126 0.0 1.3 833020 41056 ? S 15:13 0:02 /usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/main -c config_file=/etc/pos
postgres 11128 0.0 0.2 833376 7172 ? Ss 15:13 0:00 postgres: writer process
postgres 11129 0.0 0.0 833376 2240 ? Ss 15:13 0:00 postgres: wal writer process
postgres 11130 0.0 0.1 834364 3456 ? Ss 15:13 0:00 postgres: autovacuum launcher process
postgres 11131 0.0 0.0 73812 2216 ? Ss 15:13 0:00 postgres: stats collector process
postgres 11139 0.0 0.1 834356 3504 ? Ss 15:13 0:00 postgres: wal sender process replicator 192.17.30.35(60122) streaming 2/DBD84168
postgres 11139 0.0 0.1 834356 3504 ? Ss 15:13 0:00 postgres: wal sender process replicator 1992.17.30.39(60122) streaming 2/DBD84168
j'ai tester la réplication en créer une base sur le maitre, ca se réplique bien vers les deux esclaves ( les esclaves ne sont accessible qu'en lecture)
A ce moment là j'ai voulu faire le failover sur pgpool
donc j'ai créer un repertoire ou j'ai mis ce script là :
FAILED_NODE=$1
OLD_MASTER=$2
NEW_MASTER=$3
vm3='172.16.65.35'
vm5='172.16.65.39'
if test $FALLING_NODE -eq 0
then
ssh -T $vm3 touch /tmp/pgsql.trigger
ssh -T $vm5 "while test ! -f /var/lib/postgresql/9.1/main/recovery.done; do sleep 1; done; scp /var/lib/postgresql/9.1/main/pg_xlog/*history* $vm5:/var/lib/postgresql/9.1/main/pg_xlog/"
ssh -T $vm5 "sed -i 's/172.16.65.34/172.16.65.35/' /var/lib/postgresql/9.1/main/recovery.conf"
ssh -T $vm5 /etc/init.d/postgresql restart
/usr/sbin/pcp_attach_node 10 localhost 9898 pcp pcp 2
fi
~
sans oublier de mettre le parametre (failover_command = '/var/lib/postgresql/bin/failover.sh %d %M %m') sur pgpool.conf
quand j'ai fait tomber le maitre /etc/init.d/postgresql stop
le standby1 est devenue maitre mais la réplication ne marchait pas à partir du standby, c'est a dire que quand je tape ps -u postgres u je n'obtient pas comme ce que j'avais dans le maitre c'est a dire :
postgres 11139 0.0 0.1 834356 3504 ? Ss 15:13 0:00 postgres: wal sender process replicator 192.17.30.35(60122) streaming 2/DBD84168
postgres 11139 0.0 0.1 834356 3504 ? Ss 15:13 0:00 postgres: wal sender process replicator 1992.17.30.39(60122) streaming 2/DBD84168
sur /var/lib/postgresql/p.1/main/ : il n'y avait plus de fichier recovery.conf mais un fichier recovery.done ( je n'ai pas trop compris ça )
j'ai voulu revenir à l'etat précedent sans réussite, donc j'ai supprimer postgresql et réinstaller mais tout n'a pas été supprimé et j'ai garder mes fichiers de conf de postgres a savoir postgresql.conf et recovery.conf que j'avais recréer puisque il y'avait la meme chose sur recovery.done
quand je redémarrer postgresql il ne voulait pas il me disait il y'a un autre processus qui écoute sur le meme port donc j'ai eteint ma vm et je l'ai redemarrer .
quand je redémarre postgres il se redémarre normalement mais quand je check la replication sur mon serveur maitre (comme à l'etat d'origine ) ça ne marche pas.
quand je voi les log du standby1 c'est marqué :
014-07-16 17:00:55 CEST LOG: instruction : SELECT d.datname as "Name",
pg_catalog.pg_get_userbyid(d.datdba) as "Owner",
pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding",
d.datcollate as "Collate",
d.datctype as "Ctype",
pg_catalog.array_to_string(d.datacl, E'\n') AS "Access privileges"
FROM pg_catalog.pg_database d
ORDER BY 1;
2014-07-16 17:00:56 CEST LOG: instruction : SELECT d.datname as "Name",
pg_catalog.pg_get_userbyid(d.datdba) as "Owner",
pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding",
d.datcollate as "Collate",
d.datctype as "Ctype",
pg_catalog.array_to_string(d.datacl, E'\n') AS "Access privileges"
FROM pg_catalog.pg_database d
ORDER BY 1;
2014-07-16 17:00:59 CEST FATAL: le timeline 1 du serveur principal ne correspond pas au timeline 3 de la
cible de restauration
2014-07-16 17:01:04 CEST FATAL: le timeline 1 du serveur principal ne correspond pas au timeline 3 de la
cible de restauration
2014-07-16 17:01:09 CEST FATAL: n'a pas pu se connecter au serveur principal : n'a pas pu se connecter au serveur : Connexion refus?e
Le serveur est-il actif sur l'h?te << 172.16.65.34 >> et accepte-t-il les connexions
TCP/IP sur le port 5432 ?
2014-07-16 17:01:14 CEST FATAL: le timeline 1 du serveur principal ne correspond pas au timeline 3 de la
cible de restauration
2014-07-16 17:01:19 CEST FATAL: le timeline 1 du serveur principal ne correspond pas au timeline 3 de la
cible de restauration
2014-07-16 17:01:24 CEST FATAL: le timeline 1 du serveur principal ne correspond pas au timeline 3 de la
cible de restauration
Merci,
Si vous voulez plus d'explications pour pouvoir m'aider je suis là
Hors ligne
le standby1 est devenue maitre mais la réplication ne marchait pas à partir du standby, c'est a dire que quand je tape ps -u postgres u je n'obtient pas comme ce que j'avais dans le maitre c'est a dire :
postgres 11139 0.0 0.1 834356 3504 ? Ss 15:13 0:00 postgres: wal sender process replicator 192.17.30.35(60122) streaming 2/DBD84168
postgres 11139 0.0 0.1 834356 3504 ? Ss 15:13 0:00 postgres: wal sender process replicator 1992.17.30.39(60122) streaming 2/DBD84168
Ça me paraît normal. le deuxième esclave n'est pas au courant que le premier esclave est devenu maître. Et l'ancien maître est mort.
sur /var/lib/postgresql/p.1/main/ : il n'y avait plus de fichier recovery.conf mais un fichier recovery.done ( je n'ai pas trop compris ça )
La bascule a arrêté la restauration, donc PostgreSQL a renommé le fichier recovery.conf en recovery.done pour éviter qu'il re-rentre en restauration après un redémarrage.
Guillaume.
Hors ligne
Je vous remercie pour votre réponse.
Comment faire alors pour tenir le deuxième standby au courant ? comment faire pour avoir la même configuration qu'avant mais avec un nouveau maitre, tout en rallumant l'ancien maitre que j'avais coupé.
Sans le recovery.conf comment le nouveau maitre va savoir qu'il doit communiquer avec l'autre standby et l'ancien maitre que j'ai rallumer.
est ce possible après un failover de retrouver les mêmes propriétés qu'avant mais avec un nouveau maitre c'est a dire :
je fais un failover je rallume l'ancien maitre que j'ai fait tomber.Le nouveau maitre doit avoir les wal sender vers le deuxieme standby et l'ancien maitre que j'ai rallumé.Et par rapport a pgpool2 est ce qu'il peut gérer tout ça car j'ai vu le pcp_promote_node .
Merci
Hors ligne
Bonjour,
En supposant que vous êtes en mode master/slave.
Il faut reconstruire les esclaves par rapport au nouveau maitre.
Dans le pgpool.conf, pour mettre en œuvre l'online recovery, il faut paramétrer ceci :
recovery_1st_stage_command = 'basebackup.sh'
basebackup.sh est un script shell qui doit faire ceci :
- suppression des fichiers du nœud à restaurer (esclave)
- sauvegarde à chaud du nouveau maitre/restauration du maitre vers le nœud à restaurer
- suppression des fichiers inutiles pour la restauration (sur l'esclave): postmaster.pid, recovery.done, xlog
- modification et création du recovery.conf (sur l'esclave)
- modification du postgresql.conf (sur l'esclave)
Prévoir un script de démarrage des instances (cherchez pgpool_remote_start sur internet)
Cordialement,
Cordialement,
Sébastien.
Hors ligne
Bonjour,
J'ai bien compris ce que vous avez dis, mais quand je fais ça manuellement ça ne marche pas.
je me met sur mon master et j'execute
rsync --exclude pg_xlog -av --delete /var/lib/postgresql/9.1/main/ root@192.17.30.35:/var/lib/postgresql/9.1/main/le 192.17.30.35 c'est mon standby qui ne veut plus répliquer, la conf est bonne j'ai mon recovery.conf la conf postgresql est bonne.
quand je vois les log de ce standby il me donne :
2014-07-17 10:33:09 CEST FATAL: le timeline 1 du serveur principal ne correspond pas au timeline 3 de la
cible de restaurationma config est :
postgres=# show pool_nodes;
node_id | hostname | port | status | lb_weight | role
---------+--------------+------+--------+-----------+---------
0 | 192.17.30.34 | 5432 | 2 | 0.333333 | primary
1 | 192.17.30.35 | 5432 | 3 | 0.333333 | standby
2 | 192.17.30.39| 5432 | 2 | 0.333333 | standbyHors ligne
Bonjour,
avez vous effacé les fichiers du 192.17.30.35 avant de faire le rsync ?
avez vous fait le pg_start_backup avant le rsync sur le maitre puis pg_stop_backup ?
avez vous bien configurer le parametre archive_command de postgresql.conf pour envoyer les archives aussi sur l'esclave ?
Dernière modification par ruizsebastien (17/07/2014 11:11:56)
Cordialement,
Sébastien.
Hors ligne
Bonjour ,
J'ai fait tout ça mais rien du tout.
J'ai supprimer postgresql et je l'ai réinstaller.
J'ai remis les configuration qu'il faut pour la streaming replication et la connexion avec pgpool comme avant.
le serveur démarre mais ne fait pas de replication, quand je regarde les log je trouve :
2014-07-17 12:18:52 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-17 12:18:53 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attenteMerci pour votre aide.
Hors ligne
et quand je veux me connecter a postgres il ne veut pas :
root@vm3:/var/lib/postgresql/9.1/main# su - postgres
postgres@vm3:~$ psql -lt
psql: FATAL: le syst?me de bases de donn?es se lance
postgres@vm3:~$ Hors ligne
vérifiez les droits et le propriétaire des fichiers de votre instance en standby.
Cordialement,
Sébastien.
Hors ligne
j'ai vérifier les droits tout est ok.
j'ai fait :
chown -R postgres: /var/lib/postgresql/9.1/main/ et chown -R postgres: /etc/postgresql/9.1/main Le meme problème survient.
2014-07-17 14:14:40 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-17 14:14:40 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.Hors ligne
dans le postgresql.conf de l'esclave :
restore_command = 'cp /chemin vers archives/%f %p'
standby_mode = 'on'
primary_conninfo = 'host=host du maitre port=5432 user=postgres'
trigger_file = '/tmp/stopstandby'
hot_standby = on
supprimer : max_wal_senders = xxxx et archive_mode =on
SUR LE MAITRE :
archive_mode = on
archive_command = 'votre commande'
archive_timeout = 3600
wal_level = hot_standby
max_wal_senders = 3 #mettre ici au minimum le nb de clusters slaves
------
en complément pourrait-on avoir le contenu complet du log postgres de l'esclave juste après le redémarrage (la prmière fois juste après la copie rsync) ?
Dernière modification par ruizsebastien (17/07/2014 16:31:36)
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Je vous montre ma configuration :
le fichier postgresql de l'esclave :
les différences entre les deux sont :
80c80
< #ssl = true # (change requires restart)
---
> ssl = true # (change requires restart)
154d153
<
166c165
< wal_buffers =-1 # min 32kB, -1 sets based on shared_buffers
---
> wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers
197c196
< max_wal_senders = 3 # max number of walsender processes
---
> max_wal_senders =3 # max number of walsender processes
211c210
< hot_standby = on # "on" allows queries during recovery
---
> hot_standby = off # "on" allows queries during recovery
245c244
< #random_page_cost = 4.0 # same scale as above
---
> random_page_cost = 4.0 # same scale as above
277c276
< log_destination = 'stderr' # Valid values are combinations of
---
> #log_destination = 'stderr' # Valid values are combinations of
399c398< log_statement = 'all' # none, ddl, mod, all
---
> log_statement = 'none' # none, ddl, mod, allSur le standby le fichier recovery.conf : /var/lib/postgresql/9.1/main/recovery.conf
standby_mode = 'on'
primary_conninfo = 'host=192.17.30.34 port=5432 user=replicator password=rep '
trigger_file = '/tmp/pgsql.trigger'Sur le fichier pg_hba du maitre et l'esclave tout les autorisation de connexion sont mentionné.
Sur mon maitre je fais un rsync
rsync --exclude pg_xlog -av --delete /var/lib/postgresql/9.1/main/ root@192.17.30.35:/var/lib/postgresql/9.1/main/ Sur les log du standby on me donne pas grand information :
2014-07-18 09:25:04 CEST LOG: paquet de d?marrage incomplet
2014-07-18 09:25:04 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:05 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:05 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:06 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:06 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:07 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:07 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:08 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:08 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:09 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:25:09 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:25:09 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:10 CEST FATAL: le syst?me de bases de donn?es se lance
2014-07-18 09:25:10 CEST LOG: paquet de d?marrage incomplet
2014-07-18 09:25:14 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
2014-07-18 09:49:00 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:49:00 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:49:05 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:49:05 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:49:10 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:49:10 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:49:15 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:49:15 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:49:20 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:49:20 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:49:25 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:49:25 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:49:30 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:49:30 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:49:35 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:49:35 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:49:40 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:49:40 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:49:45 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attente
2014-07-18 09:49:45 CEST D?TAIL: L'identifiant du serveur principal est 6029142299729714430, l'identifiant du serveur en attente
est 6036952324097693111.
2014-07-18 09:49:50 CEST FATAL: l'identifiant du syst?me de bases de donn?es diff?re entre le serveur principal
et le serveur en attenteCette erreur il a fait en continue chaque 5 seconde je la voi apparaitre sur les logs
Sachant que cette même configuration marchait parfaitement avant que je ne fasse le failover !
Dernière modification par yassine199105 (21/07/2014 11:20:09)
Hors ligne
et sur pgpool :
le statut du noeud 1 192.17.30.35 est toujours 3 ( down) meme si je fais un pcp_attach_node
Hors ligne
Pouvez vous me donner le résultat de :
sur le maitre :
select * from pg_settings where name ='archive_mode';
sur l'esclave :
select * from pg_settings where name ='hot_standby';
et j'ai l'impression qu'il manque archive_command sur le maitre.
sur le maitre + l'esclave :
ps -ef |grep postgres
paquets installés :
rpm -qa |grep postgres
Dernière modification par ruizsebastien (18/07/2014 11:10:10)
Cordialement,
Sébastien.
Hors ligne
Je n 'ai pas mis archive_commande car avant que je ne fasse le failover je n'avais pas fait ça, et la réplication marchait bien, maintenant je veux juste revenir comme avant.
comment je peux configurer tout ça ? je suis un peu perdu
sur mon premier standby je ne peux pas executer
select * from pg_settings where name ='hot_standby';car je n'ai meme pas acces a la base par contre le standby 2 qui marche parfaitement et fait de la réplication avec le master voilà le resulat :
postgres=# select * from pg_settings where name ='hot_standby';
name | setting | unit | category | short_desc | extra_desc | context | vartype | s
ource | min_val | max_val | enumvals | boot_val | reset_val | sourcefile | sourceline
-------------+---------+------+-------------------------------+-------------------------------------------------+------------+------------+---------+--------
------------+---------+---------+----------+----------+-----------+------------------------------------------+------------
hot_standby | on | | Replication / Standby Servers | Allows connections and queries during recovery. | | postmaster | bool | configu
ration file | | | | off | on | /etc/postgresql/9.1/main/postgresql.conf | 210
(1 lig sur le master :
postgres=# select * from pg_settings where name ='archive_mode';
name | setting | unit | category | short_desc | extra_desc | context | vartype | sou
rce | min_val | max_val | enumvals | boot_val | reset_val | sourcefile | sourceline
--------------+---------+------+-----------------------------+------------------------------------------------------+------------+------------+---------+----
-----+---------+---------+----------+----------+-----------+------------+------------
archive_mode | off | | Write-Ahead Log / Archiving | Allows archiving of WAL files using archive_command. | | postmaster | bool | def
ault | | | | off | off | |
(1 ligne)je suis vraiment bloqué et perdu ( ça fait qu'un mois que j'ai commencer postgres )
Je vous remercie de votre compréhension.
J'ai lu beaucoup de documents mais ce n'est jamais suffisant 
Dernière modification par yassine199105 (18/07/2014 11:37:53)
Hors ligne
Un point essentiel, il faut avoir la même version de postgresql partout !
(que donne rpm -qa |grep postgres sur vos différents serveurs ?)
déjà il est essentiel de mettre archive_mode = on sur le maître
ensuite il faut envoyer les archives générées par le maître sur le serveur des esclaves.
Par faire ça je passe par un script par exemple nommé "archive_command_standby.sh (paramètres à adapter selon votre conf) :
(dans mon exemple, les archives sont multiplexées sur le maîtres (2 répertoires))
#!/bin/sh
# Shell d'archive_command standbyCLUSTER=$1
CHEMIN=$2
FICHIER=$3
ARCHIVE1=/${CLUSTER}_1/archive
ARCHIVE2=/${CLUSTER}_2/archive
LOGFILE=/${CLUSTER}_1/admin/${CLUSTER}_arch_process.logcp $CHEMIN $ARCHIVE1/$FICHIER >>/${LOGFILE} 2>&1
ret=$?
cp $ARCHIVE1/$FICHIER $ARCHIVE2/$FICHIER >>/${LOGFILE} 2>&1
#mettre ici tous les noeuds primary et slaves :
rsync -a $CHEMIN postgres@ip_serveur_maître:$ARCHIVE1/$FICHIER >>/${LOGFILE} 2>&1
rsync -a $CHEMIN postgres@ip_serveur_esclave:$ARCHIVE1/$FICHIER >>/${LOGFILE} 2>&1
let ret=$ret+$?
exit $ret
dans le postgresql.conf du master :
archive_mode = on
archive_command = '/chemin_vers_script/archive_command_standby.sh nom_du_cluster %p %f'
archive_timeout = 3600
wal_level = hot_standby
max_wal_senders = 3 #mettre ici au minimum le nb de clusters slaves
Mettez le pg_hba.conf en mode trust (sur tous les serveurs pour éviter les blocage dans un premier temps.
Relancer le cluster maître pour prendre en compte les paramètres.
Ensuite, copier le maître sur l'esclave (tout copier, wal, data, admin, etc...) :
psql -p 5432 -c "select pg_start_backup('sav1', true)" postgres
rsync -azuv /chemin_des_datas_maître/* postgres@ip_esclave:/chemin_des_datas_esclave/
psql -p 5432 -c "select pg_stop_backup()" postgres
sur l'esclave, effacer les fichiers suivants :
postmaster.pid
recovery.done
pg_xlog/*
pg_log/*
sur l'esclave, modifier le postgresql.conf :
supprimer : max_wal_senders = 3
ajouter : hot_standby = on
sur l'esclave, créez un fichier recovery.conf dans le repertoire admin :
restore_command = 'cp /chemin_vers_les_archives/%f %p'
standby_mode = 'on'
primary_conninfo = 'host=ip_maître port=5432 user=postgres'
trigger_file = '/tmp/stopstandby'
démarrer l'esclave :
pg_ctl start -D /répertoire_démarrage/admin
et normalement si vous avez tout suivi ça marche...
Cordialement,
Sébastien.
Hors ligne
root@vm2:/etc/postgresql/9.1/main# rpm -qa |grep postgres
-bash: rpm : commande introuvableHors ligne
j'ai la même version de postgres partout , les même paquet partout , je travaille avec la version postgresql 9.1
quand je fait
dpkg -l |grep postgres je trouve les mêmes paquets partout.
Pour le script archive_command_standby.sh qu'est ce qu'il y'a a changer a part les adresses IP pour le rsync ?
Pour les archives c'est que pg_xlog ?
merci beaucoup pour votre aide
Dernière modification par yassine199105 (18/07/2014 12:47:40)
Hors ligne
Pour le script archive_command_standby.sh :
il faut changer l'ip et le chemin où se trouvent les archives.
pg_xlog et archives sont différents :
pg_xlog contient les journaux de transaction (wal) tandis que les archives contiennent les fichers wal archivés par la commande archive_command.
----------
autre chose dans le pg_hba.conf de l'esclave il faut ajouter la ligne :
host replication postgres ip_du_maitre/24 md5
Dernière modification par ruizsebastien (18/07/2014 14:32:54)
Cordialement,
Sébastien.
Hors ligne
Je ne sais pas ou se trouve le chemin vers les archives et je ne vois pas a quel partie du script remplacer ce chemin !
Pourquoi avant que je ne fasse le failover tout marchait bien sans que je ne fasse ça ?
#!/bin/sh
# Shell d'archive_command standby
CLUSTER=$1
CHEMIN=$2
FICHIER=$3
ARCHIVE1=/${CLUSTER}_1/archive
ARCHIVE2=/${CLUSTER}_2/archive
LOGFILE=/${CLUSTER}_1/admin/${CLUSTER}_arch_process.log
cp $CHEMIN $ARCHIVE1/$FICHIER >>/${LOGFILE} 2>&1
ret=$?
cp $ARCHIVE1/$FICHIER $ARCHIVE2/$FICHIER >>/${LOGFILE} 2>&1
#mettre ici tous les noeuds primary et slaves :
rsync -a $CHEMIN postgres@192.17.30.34:$ARCHIVE1/$FICHIER >>/${LOGFILE} 2>&1
rsync -a $CHEMIN postgres@192.17.30.35:$ARCHIVE1/$FICHIER >>/${LOGFILE} 2>&1
rsync -a $CHEMIN postgres@192.17.30.39:$ARCHIVE1/$FICHIER >>/${LOGFILE} 2>&1
let ret=$ret+$?
exit $ret Je vous remercie encore une fois pour votre aide .
Hors ligne
c'est vous qui choisissez le chemin des archives.
Cordialement,
Sébastien.
Hors ligne
Je pense qu'avant même de chercher à automatiser quoi que ce soit avec pgpool, il serait bon de bien comprendre la réplication interne de PostgreSQL. Notamment le fait qu'il n'est pas possible de faire de switchover sans avoir à reconstruire entièrement l'esclave.
Guillaume.
Hors ligne
Bonjour,
Effectivement j'ai lu les docs de postgresql et j'ai vu qu'il fallait reconstruire entièrement l'esclave, mais est-ce-possible de faire ça avec le online recovery à partir du nouveau maitre ?
ou bien il faut reconstruire manuellement l'ancien maitre après l'avoir démarré en créant le recovery.conf et postgresql.conf du standby et en synchronisant le nouveau maitre avec l'ancien maitre ( qui est maitenant esclave) ?
Hors ligne
En fait je ne vois pas la procédure globale qu'il faut faire après un failover :
Voilà ce que j'ai fait et ça ne marche pas :
j'ai un serveur pgpool et 3 serveurs postgres ( 1 master / 2 standby ) lorsque je stoppe le master, pgpool fait le failover.
vm3 : premier standby ( qui va devenir maitre après failover)
vm5:deuxieme standby
192.17.30.34: c'est le master avant failover
Dans le maitre j'ai
archive_command = 'test ! -f /var/lib/postgresql/9.1/archiving_active || cp -i %p /var/lib/postgresql/9.1/archive/%f'archiving_active est un fichier vide que j'ai créer dans le répertoire /var/lib/postgresql/9.1/archive ( je n'ai pas compris comment faire pour l'archive )
le script que sebastien m'a donné je n'ai pas trop compris ce qu'il fallait remplacer et ou mettre le chemin dans le script :
#!/bin/sh
# Shell d'archive_command standby
CLUSTER=$1
CHEMIN=$2
FICHIER=$3
ARCHIVE1=/${CLUSTER}_1/archive
ARCHIVE2=/${CLUSTER}_2/archive
LOGFILE=/${CLUSTER}_1/admin/${CLUSTER}_arch_process.log
cp $CHEMIN $ARCHIVE1/$FICHIER >>/${LOGFILE} 2>&1
ret=$?
cp $ARCHIVE1/$FICHIER $ARCHIVE2/$FICHIER >>/${LOGFILE} 2>&1
#mettre ici tous les noeuds primary et slaves :
rsync -a $CHEMIN postgres@192.17.30.34:$ARCHIVE1/$FICHIER >>/${LOGFILE} 2>&1
rsync -a $CHEMIN postgres@192.17.30.35:$ARCHIVE1/$FICHIER >>/${LOGFILE} 2>&1
let ret=$ret+$?
exit $ret Est-ce ce script là qui permet l'archivage des WAL ?
Voila mon script failover.sh
FAILED_NODE=$1
OLD_MASTER=$2
NEW_MASTER=$3
vm3='192.17.30.35'
vm5=192.17.30.39'
if test $FAILED_NODE -eq 0
then
ssh -T $vm3 touch /tmp/pgsql.trigger
ssh -T $vm3 "while test ! -f /var/lib/postgresql/9.1/main/recovery.done; do sleep 1; done; scp /var/lib/postgresql/9.1/main/pg_xlog/*history* $vm5:/var/lib/postgresql/9.1/main/pg_xlog/"
ssh -T $vm5 "sed -i 's/192.17.30.34/192.17.30.35/' /var/lib/postgresql/9.1/main/recovery.conf"
ssh -T $vm5 /etc/init.d/postgresql restart
/usr/sbin/pcp_attach_node 10 localhost 9898 pcp pcp 2
fi
~ Sur pgpool.conf j'ai :
failover_command = '/var/lib/postgresql/bin/failover.sh %d %M %m' Une fois après avoir fait ça quand je vais sur le premier standby, je remarque bien qu'il est devenue maitre et que le recovery.conf est devenue recovery.done
donc j'ai transférer le fichier de conf du standby2 a l'ancien maitre et j'ai créer dans l'ancien maitre le recovery.conf pour qu'il devienne standby après j'ai un rsync du nouveau maitre avec l'ancien maitre ( qui est esclave maintenant) :
rsync --exclude pg_xlog -av --delete /var/lib/postgresql/9.1/main/ root@192.17.30.34:/var/lib/postgresql/9.1/main/ les autorisation de connexions sont bien mentionnés dans le pg_hba des 3 serveurs.
est-ce-qu'il manque quelquechose ou bien je me suis trompé quelque part ?
Ce que je voudrais savoir aussi c'est comment rétablir la réplication après avoir fait le failover c'est a dire pouvoir répliquer a partir du nouveau master vers l'ancien maitre ( qui est standby) et le standby2 ?
Merci pour votre aide.
Dernière modification par yassine199105 (21/07/2014 14:01:12)
Hors ligne
bonjour,
Oui c'est possible de le faire avec online recovery.
par contre vous devez (comme le dit Gleu plus haut) bien comprendre le processus de réplication postgresql.
Et en premier lieu le principe d'archivage.
Pour info il faut donner à postgres un répertoire (pas un fichier) pour qu'il puisse stocker ses archives (sur chaque serveur).
Cordialement,
Sébastien.
Hors ligne
Pages : 1