Forums PostgreSQL.fr

yassine199105

Membre

Problème avec failover

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à

gleu

Administrateur

Re : Problème avec failover

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.

yassine199105

Membre

Re : Problème avec failover

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

ruizsebastien

Membre

Re : Problème avec failover

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.

yassine199105

Membre

Re : Problème avec failover

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 restauration

ma 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  | standby

ruizsebastien

Membre

Re : Problème avec failover

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.

yassine199105

Membre

Re : Problème avec failover

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 attente

Merci pour votre aide.

yassine199105

Membre

Re : Problème avec failover

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:~$ 

ruizsebastien

Membre

Re : Problème avec failover

vérifiez les droits et le propriétaire des fichiers de votre instance en standby.

---

Cordialement,

Sébastien.

yassine199105

Membre

Re : Problème avec failover

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.

ruizsebastien

Membre

Re : Problème avec failover

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.

yassine199105

Membre

Re : Problème avec failover

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, all

Sur 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 attente

Cette 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)

yassine199105

Membre

Re : Problème avec failover

et sur pgpool :
le statut du noeud 1  192.17.30.35 est toujours 3 ( down) meme si je fais un pcp_attach_node

ruizsebastien

Membre

Re : Problème avec failover

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.

yassine199105

Membre

Re : Problème avec failover

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)

ruizsebastien

Membre

Re : Problème avec failover

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

yassine199105

Membre

Re : Problème avec failover

root@vm2:/etc/postgresql/9.1/main# rpm -qa |grep postgres 
-bash: rpm : commande introuvable

yassine199105

Membre

Re : Problème avec failover

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)

ruizsebastien

Membre

Re : Problème avec failover

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.

yassine199105

Membre

Re : Problème avec failover

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 .

ruizsebastien

Membre

Re : Problème avec failover

c'est vous qui choisissez le chemin des archives.

---

Cordialement,

Sébastien.

gleu

Administrateur

Re : Problème avec failover

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.

yassine199105

Membre

Re : Problème avec failover

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) ?

yassine199105

Membre

Re : Problème avec failover

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)

ruizsebastien

Membre

Re : Problème avec failover

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.