Vous n'êtes pas identifié(e).
Bonjour,
Je vous remercie beaucoup, vous m'avez lancer sur la bonne piste. J'ai fait un ALTER ROLE et ça marche.
Bonjour,
Je suis en architecture 1 maitre et 2 esclaves en streaming replication, pgpool étant relié à mes 3 serveurs en réplication.
J'ai un serveur WEB apache chargé avec le module prefork. Je lance des URL à partir de Jmeter qui utilisent des requêtes HTTP sur ma base.
Pgpool ne veut pas balancer les requêtes vers les esclaves ... ( je ne sais pour quelle raison )
L'erreur sur les logs du serveur apache et les log des standby est la même : la relation de la table machin n'existe pas. Il n'arrive pas a faire le set search path
Pgpool envoi quand même toutes les requêtes qu'au serveur maitre.
Sur pgpool je suis avec cette configuration :
Mode master/slave : stream
Load balancing : on
parallel request : OFF
..
J'ai vu les restrictions de pgpool, mais la doc précise bien qu'il ne résoud pas les schéma qu'en mode Parellel request qui est désactivé dans mon cas.
Si vous avez besoin de plus d'informations , dites le moi.
Je vous remercie .
Je vous remercie pour toutes ces précisions qui m'ont beaucoup aider à voir plus clair sur ce sujet.
Bonjour,
Du rsync depuis le maître vers les esclaves. Les données des transactions ne sont pas synchronisées dans les journaux de transaction Ou,comment sont alors synchronisé les données de transactions ?
Merci.
Oui je fais de tests de montée en charge. Avec fsync=off on perd toutes les données ???
Je n'exclut pas le pg_xlog car je n'ai pas mis en place l'archivage des WAL. J'ai essayer avec le exclude pg_xlog mais ça me fait état de restauration incohérent car le streaming replication ne peut pas rattraper tout son retard si l'archivage n'est pas activé.
Merci de m'avoir éclaircit tout ça.
Oui le fsync est désactivé dans le test que je fais. Ce problème de lecture de WAL d'ou il peut venir ?
Mais j'en fait plusieurs des tests et justement le fsync c'est un paramètre que je met soit a OFF soit a ON mais le problème est présent dans les deux cas.
2014-08-18 09:42:36 CEST LOG: entre en mode standby
2014-08-18 09:42:36 CEST LOG: ?tat de restauration coh?rent atteint ? 4/C7000078
2014-08-18 09:42:36 CEST LOG: le syst?me de bases de donn?es est pr?t pour accepter les connexions en lecture seule
2014-08-18 09:42:36 CEST LOG: enregistrement avec prev-link 4/5E000020 incorrect ? 4/C7000078Voila le message dans les log des deux standby
Par contre le maitre il me met pg_stat_wait timeout
Et quand je fais le rsync :
Log du slave :
? 2014-08-20 15:43:40 CEST
2014-08-20 15:45:41 CEST LOG: entre en mode standby
2014-08-20 15:45:42 CEST LOG: paquet de d?marrage incomplet
2014-08-20 15:45:42 CEST LOG: ?tat de restauration coh?rent atteint ? 5/3E000078
2014-08-20 15:45:42 CEST LOG: enregistrement de longueur nulle ? 5/3E000078
2014-08-20 15:45:42 CEST LOG: le syst?me de bases de donn?es est pr?t pour accepter les connexions en lecture seule
2014-08-20 15:45:42 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-08-20 15:45:47 CEST LOG: r?plication de flux connect? avec succ?s au serveur principalEt après avoir fait le rsync quand je lance mon test ça devient anormalement long et il y'a trop de lecture sur le disque
Juste après si je refais le test mais sans rsync après 1 min de test les requêtes sont executé très rapidement
Je lance ce script que j'ai ecris !
ssh root@172.16.65.31 "/etc/init.d/pgpool2 stop"
ssh root@172.16.65.35 "/etc/init.d/postgresql stop"
ssh root@172.16.65.39 "/etc/init.d/postgresql stop"
/etc/init.d/postgresql stop
rsync -avz --delete --exclude /postmaster.* --exclude /recovery.* ~postgres/9.1/main/ 172.16.65.35:~postgres/9.1/main/
rsync -avz --delete --exclude /postmaster.* --exclude /recovery.* ~postgres/9.1/main/ 172.16.65.39:~postgres/9.1/main/
ssh root@172.16.65.35 "/etc/init.d/postgresql start"
ssh root@172.16.65.39 "/etc/init.d/postgresql start"
/etc/init.d/postgresql start
ssh root@172.16.65.31 "/etc/init.d/pgpool2 start; sleep 3"
ssh root@172.16.65.31 "pcp_attach_node 0 localhost 9898 pcp pcp 0;sleep 3;pcp_attach_node 0 localhost 9898 pcp pcp 1; sleep 3; pcp_attach_node 0 localhost 9898 pcp pcp 2"vu que je ne travaille pas avec l'archivage je n'exclut pas les pg_xlog au cas ou il y'aurais un retard important entre le maitre et l'esclave. mon wal_keep_segment = 100
Est ce obligatoire le pg_start_backup() et pg_stop_backup qu'est ce que je doit ajouter a mon script a votre avis ?
Bonjour,
Je ne comprend pas trop le problème.
En fait je fait de la streaming replication sans archivage ( log-shipping) mais par contre avant de lancer mon test je fait un rsync entre le maitre et les deux esclaves quand je fait ça les log des esclaves m'indique : enregistrement de longueur nulle ... streaming replication réussie. Quand je lance mon test les requêtes vers les esclaves mettent trop de temps a s'executer juste au début et après ça se rétablit mais vers le maitre ça reste long a s'executer , quand je change mes config pour faire un second test les logs des standby m'indique :
Enregistrement avec prevlink incorrect du XXX... à ce moment là quand je lance le second test mais cette fois sans faire de rsync ça balance vers les 3 et c'est rapide.
Est-ce-que le fait de ne pas archiver peut causer ces problèmes là ?
J'ai fait des recherches sur enregistrement avec prevlink incorrect mais je ne comprend pas trop pourquoi j'obtient cette erreur sachant que quand je fait un rsync cette erreur disparait et j'obtient enregistrement de longueur nulle et les requêtes deviennent longue à s'executer.
Autre remarque : des fois à la fin de l'envoi de requetes SELECT par pgpool les deux standby m'indique que la reexection commence ( ça veut dire qu'a ce moment là il rejoue les WAL si j'ai bien compris ) et des fois ça ne le fait pas et justement quand ça me fait ça le load balancing reprend.
Merci pour ton aide Julien
Bonjour ,
Je lance mon test a partir de Jmeter . J'execute des requêtes SELECT et INSERT sur ma base ! J'ai configuré Pgpool avec le mode load balancing=on les serveurs maitre et esclaves ont le même poid ! Backend_weight0 1 et 2 sont a 1 . Au moment ou je lance le test je regarde les logs de postgresql du maitre aucun message ne m'informe sur le problème que j'ai ,tout a l'air de bien se passer. Au tout début du test le IOwait est a 99% pour les 3 serveurs et il y'a beaucoup de lecture sur le disque pour les 3 serveurs mais après 2 min de test les deux esclaves se retablissent quand je fais vmstat j'obtient :
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
18 0 4916 21148 9704 2146788 0 0 0 0 519 629 99 1 0 0
13 0 4916 20900 9704 2146788 0 0 0 0 756 1149 96 4 0 0
17 0 4916 20404 9704 2146788 0 0 0 0 665 812 96 4 0 0
18 0 4916 20280 9704 2146788 0 0 0 0 497 656 98 2 0 0
17 0 4916 20156 9704 2146788 0 0 0 8 522 843 96 4 0 0
17 0 4916 20156 9704 2146788 0 0 0 0 583 719 94 6 0 0
14 0 4916 19784 9712 2146780 0 0 0 28 582 705 98 2 0 0
16 0 4916 21884 9712 2144128 0 0 0 0 564 642 97 3 0 0
16 0 4916 21768 9712 2144136 0 0 0 0 507 736 93 7 0 0même chose pour le deuxième esclave.
Mais pour le maitre je remarque que le système attend beaucoup de I/O
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 16 4884 20348 3608 2235836 0 0 67 11 43 69 0 0 98 2
0 17 4884 19232 3616 2237288 0 0 3048 0 205 342 0 1 0 99
0 17 4884 19976 3628 2236404 0 0 2804 0 216 337 2 0 0 98
0 18 4884 20472 3616 2235656 0 0 2800 0 189 327 1 1 0 98
0 18 4884 20596 3620 2235532 0 0 3468 0 198 296 0 1 0 99
0 18 4884 20100 3624 2236228 0 0 4052 0 194 306 1 1 0 98
0 18 4884 19976 3624 2236172 0 0 3616 0 210 302 0 0 0 100
0 18 4884 19356 3628 2236660 0 0 3128 0 224 334 2 2 0 96
0 18 4884 20472 3620 2235540 0 0 2616 0 201 332 1 0 0 99
0 18 4884 20472 3620 2235056 0 0 3000 0 178 306 0 1 0 99
1 17 4884 20224 3616 2235628 0 0 3820 0 188 302 1 0 0 99 tout le temps occupé a 99 %
Quand je fait un iotop sur le maitre je remarque que les select lisent beaucoup sur le disque alors que pgpool n'envoi rien au maitre ou bien très très très peu.
iotop maitre
172.16.65.31 est l'adresse de pgpool. user_base est l'utilisateur de la base ( base_2)
Total Disk Read : 2.99 M/S | Total Disk write : 0.80 B/S
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
22300 be/4 postgres 260.3 K/S 0.80 B/S 0.09 99.99% postgres: user_base base_2 172.16.65.31 (43954) SELECT
22358 be/4 postgres 299.2 K/S 0.80 B/S 0.09 99.99% postgres: user_base base_2 172.16.65.31 (43954) SELECT
22377 be/4 postgres 163.4 K/S 0.80 B/S 0.09 99.99% postgres: user_base base_2 172.16.65.31 (43954) SELECT
22385 be/4 postgres 230.8 K/S 0.80 B/S 0.09 89.99% postgres: user_base base_2 172.16.65.31 (43954) SELECT
......Sur les logs de pgpool je voit bien que mes requêtes sont distribué vers mes 2 esclave avec le même poids mais pas sur le maitre ! ( le maitre ne prend que quelques requêtes ).
Logs pgpool
Aug 19 09:45:02 vm1 pgpool[12355]: pool_send_and_wait: Error or notice message from backend: : DB node id: 2 backend pid: 23984 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-7-4 and period 6
Aug 19 09:45:02 vm1 pgpool[12328]: pool_send_and_wait: Error or notice message from backend: : DB node id: 1 backend pid: 7296 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-7-5 and period 3
Aug 19 09:45:02 vm1 pgpool[12355]: pool_send_and_wait: Error or notice message from backend: : DB node id: 2 backend pid: 23984 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-2-22 and period 5
Aug 19 09:45:02 vm1 pgpool[12328]: pool_send_and_wait: Error or notice message from backend: : DB node id: 1 backend pid: 7296 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-2-10 and period 5
Aug 19 09:45:02 vm1 pgpool[12315]: pool_send_and_wait: Error or notice message from backend: : DB node id: 1 backend pid: 7311 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-3-22 and period 4
Aug 19 09:45:02 vm1 pgpool[12300]: pool_send_and_wait: Error or notice message from backend: : DB node id: 2 backend pid: 23983 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-4-1 and period 4
Aug 19 09:45:02 vm1 pgpool[12326]: pool_send_and_wait: Error or notice message from backend: : DB node id: 1 backend pid: 7290 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-1-10 and period 3
......Au moment du lancement de test :
Sur mes esclave 1 et 2
Par contre au tout début du test quand les 3 serveurs était bloqué , pgpool a envoyé quelques requêtes au maitre ( 5 SELECT) puis plusieurs aux deux eslaves puis il a afficher sur les logs
:
Aug 19 09:38:52 vm1 pgpool[12361]: pool_send_and_wait: Error or notice message from backend: : DB node id: 1 backend pid: 7314 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-2-2 and period 3
Aug 19 09:38:54 vm1 pgpool[12355]: pool_send_and_wait: Error or notice message from backend: : DB node id: 2 backend pid: 23984 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-5-12 and period 4
Aug 19 09:38:55 vm1 pgpool[12331]: pool_send_and_wait: Error or notice message from backend: : DB node id: 2 backend pid: 23963 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-3-16 and period 6
Aug 19 09:38:59 vm1 pgpool[12343]: pool_send_and_wait: Error or notice message from backend: : DB node id: 2 backend pid: 23995 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-2-22 and period 2
Aug 19 09:39:01 vm1 /USR/SBIN/CRON[12386]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Aug 19 09:39:02 vm1 pgpool[12316]: pool_send_and_wait: Error or notice message from backend: : DB node id: 2 backend pid: 23977 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-3-13 and period 5
Aug 19 09:39:04 vm1 pgpool[12304]: pool_send_and_wait: Error or notice message from backend: : DB node id: 1 backend pid: 7287 statement: select jmaplink_bench_query(6,5,2014) message: Performing query for date 2014-7-19 and period 2Je ne pense pas que c'est un problème matériel parce que mon slave 2 a une disque qui est neuf
Bonjour,
Effectivement quand je fait un iotop sur le maitre je remarque qu'il y'a trop de lecture sur le disque et c'est les requêtes que je lance avec jmeter à partir de pgpool qui font ces lectures là pourtant je ne vois aucune requête select passer par pgpool on regardant les logs de ce dernier c'est ce que je trouve étrange.
Mon disque à l'air de bien focntionner je ne comprend pas pourquoi je vois beaucoup de requêtes SELECT en lecture sur le disque et lecture passer alors que pgpool n'envoi rien du tout.
Effectivement mon master ne bosse pas quand je lance mes requêtes à partir de Jmeter tandis que le slave 1 et slave 2 bossent.
Quand je fais un top sur le master je remarque bien que le master ne bosse pas :
Master :
top - 14:53:12 up 2:41, 2 users, load average: 15,46, 14,89, 7,53
Tasks: 111 total, 1 running, 110 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 3009628 total, 2989700 used, 19928 free, 3436 buffers
KiB Swap: 2097148 total, 2028 used, 2095120 free, 2711084 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 10648 692 652 S 0,0 0,0 0:00.82 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:00.30 ksoftirqd/0
4 root 20 0 0 0 0 S 0,0 0,0 0:00.41 kworker/0:0
5 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/u:0
6 root rt 0 0 0 0 S 0,0 0,0 0:00.00 migration/0
7 root rt 0 0 0 0 S 0,0 0,0 0:00.04 watchdog/0
8 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 cpuset
9 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 khelper
10 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kdevtmpfs
11 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 netns
12 root 20 0 0 0 0 S 0,0 0,0 0:00.00 xenwatch
13 root 20 0 0 0 0 S 0,0 0,0 0:00.00 xenbus
14 root 20 0 0 0 0 S 0,0 0,0 0:00.01 sync_supers
15 root 20 0 0 0 0 S 0,0 0,0 0:00.00 bdi-default
16 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kintegrityd
17 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kblockd ainsi le vmstat 1 en plein test me donne les statistiques :
Master :
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 13 2024 20732 2676 2783540 0 0 698 4 185 227 4 1 87 9
0 13 2024 19988 2680 2784372 0 0 3692 0 205 347 1 1 0 98
0 14 2024 19740 2688 2784572 0 0 3400 0 198 303 0 1 0 99
0 14 2024 19740 2696 2784564 0 0 3832 0 207 313 1 0 0 99
0 14 2024 19120 2696 2784988 0 0 3200 0 373 388 31 3 0 66
0 14 2024 19244 2700 2784916 0 0 2836 0 192 303 2 2 0 96
0 13 2024 20608 2708 2783080 0 0 3528 0 212 351 0 2 0 98
0 14 2024 20236 2708 2783836 0 0 3752 0 231 296 1 1 0 98
0 13 2024 19740 2712 2784064 0 0 3564 0 224 315 1 1 0 98tandis que le vmstat 1 du slave :
procs -----------memory---------- ---swap-- -----io---- -system-- ----
r b swpd free buff cache si so bi bo in cs us s
20 0 6120 21392 31528 2709436 1 2 240 356 103 131 4
20 0 6120 21268 31528 2709436 0 0 0 0 545 482 98
20 0 6120 21268 31528 2709436 0 0 0 0 667 726 99
20 0 6120 21128 31528 2709436 0 0 0 0 620 660 97
20 0 6120 21136 31528 2709436 0 0 0 0 549 528 98
20 0 6120 21136 31528 2709436 0 0 0 0 587 649 97
20 0 6120 21136 31536 2709428 0 0 0 16 738 925 97 Ce que je ne comprend pas c'est pourquoi le master ne veut plus bosser et me fait pg_stat_timeout et puis pgpool ne veux plus balancer la requête vers le master il ne balance que vers les deux slaves.
Je remarque que le BI est beaucoup plus supérieur que les slaves c'est la seul différence ce qui confirme que j'ai beaucoup d'entrées et sorties sur mon système
je ne vois pas comment remédier à cela
Merci pour votre réponse.
Effectivement j'ai vu les stat du système sur mes 3 machines , et je me rend compte que sur mon master ou le disque est saturée active memory est a bloc alors que sur mes deux autres standby qui fonctionne bien il y'a beaucoup de mémoire inactive.
A votre avis comment remédier a cela pour que je puisse continuer mes tests ?
Voila ce que me donne la commande vmstat -s
Sur le master
3009628 K total memory
2983356 K used memory
2432432 K active memory
508836 K inactive memory
26272 K free memory
5948 K buffer memory
2927996 K swap cache
2097148 K total swap
2052 K used swap
2095096 K free swap
33567 non-nice user cpu ticks
0 nice user cpu ticks
3724 system cpu ticks
186557 idle cpu ticks
57095 IO-wait cpu ticks
1 IRQ cpu ticks
280 softirq cpu ticks
149 stolen cpu ticks
5671177 pages paged in
34600 pages paged out
0 pages swapped in
514 pages swapped out
1538692 interrupts
1778698 CPU context switches
1408011094 boot time
2808 forksSur le slave :
3009628 K total memory
2982936 K used memory
738908 K active memory
2143864 K inactive memory
26692 K free memory
23376 K buffer memory
2849936 K swap cache
0 K total swap
0 K used swap
0 K free swap
727972 non-nice user cpu ticks
0 nice user cpu ticks
93971 system cpu ticks
7681360 idle cpu ticks
165598 IO-wait cpu ticks
4 IRQ cpu ticks
2255 softirq cpu ticks
576 stolen cpu ticks
26033073 pages paged in
51266144 pages paged out
0 pages swapped in
0 pages swapped out
15172765 interrupts
18458776 CPU context switches
1407927019 boot time
25334 forksEffectivement je voit que le master utilise beaucoup de mémoire .
Pareil dans /proc/meminfo
Bonjour ,
Je lance des tests avec jmeter sur mes serveurs en streaming réplication 1 maitre et 2 esclaves en changeant de configuration a chaque fois après plusieurs tests pgpool ne fait plus le load balancing correctement et mon serveur maitre me renvoi un warning pg_stat_wait timeout j'ai pas mal chercher sur google mais je n'ai pas trouver de réponse qui m'aide vraiment a trouver une solution a mon problème, chaque test que je fait lance environ 17 000 requête select et 70 000 insert en faisant un rollback derrière pour les insert.
A priori il y'a trop d'entrées et sorties sur mon système ou bien le disque est saturé j'ai essayer de rebooter la machine mais rien à faire mes requêtes deviennent lente quand j'ai ce message de warning s'affiche, mon fichier pgstat.stat ne fait que 76K sur /var/lib/postgresql/9.1/main/pg_stat_tmp/pgstat.stat.
Merci pour votre aide.
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.
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) ?
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 .
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
root@vm2:/etc/postgresql/9.1/main# rpm -qa |grep postgres
-bash: rpm : commande introuvableJe 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 
et sur pgpool :
le statut du noeud 1 192.17.30.35 est toujours 3 ( down) meme si je fais un pcp_attach_node
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 !
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.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:~$ 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.