Vous n'êtes pas identifié(e).
Pages : 1
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.
Dernière modification par yassine199105 (14/08/2014 11:39:57)
Hors ligne
Le message du wait timeout indique en effet un système disque très lent. vmstat permettrait de savoir ce qu'il en ait.
Guillaume.
Hors ligne
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 forks
Sur 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 forks
Effectivement je voit que le master utilise beaucoup de mémoire .
Pareil dans /proc/meminfo
Dernière modification par yassine199105 (14/08/2014 13:16:55)
Hors ligne
Cela montre juste que la majorité de votre mémoire est utilisée comme cache disque, ce qui est normal.
Essayez plutôt « vmstat 1 » par exemple pour voir l'utilisation des disques durant vos tests.
Julien.
https://rjuju.github.io/
En ligne
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 98
tandis 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
Hors ligne
Il manque une partie du vmstat de l'esclave. De ce que je vois sur le maître, le serveur est constamment en attente de disque (iowait à 98%) avec uniquement des lectures sur disque effectuées. Sur l'esclave, il semble utiliser uniquement du cpu, sans iowait. Ce comportement est plutôt inhabituel. Même si pgpool est jmeter sont exécutés sur cette machine, je vois mal cela consommer toutes les ressources. N'auriez-vous pas un disque défectueux sur votre serveur maître ?
Julien.
https://rjuju.github.io/
En ligne
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.
Hors ligne
Vous voyez beaucoup de SELECT en lecture sur le maître ou vous voyez beaucoup de lecture disque sur le maître ? Votre vmstat plafonne à 15 Mo/s en lecture. Soit il s'agit de lecture aléatoires hors du cache uniquement, soit il y a un gros problème matériel.
Quelles sont les requêtes que vous exécutez avec jmeter ? Quelle est la configuration de pgpool concernant le load balancing ? Y a -t-il des messages dans les logs de postgres ou pgpool durant vos tests ? Sans plus d'information on ne peut vous donner plus d'aide.
Julien.
https://rjuju.github.io/
En ligne
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 0
mê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 2
Je ne pense pas que c'est un problème matériel parce que mon slave 2 a une disque qui est neuf
Dernière modification par yassine199105 (19/08/2014 10:07:25)
Hors ligne
Le iotop sur le maître affiche moins de 3 Mo/s en lecture et 99.99% d'IO utilisés, avec moins de 300 Ko/s par client. Je pense que tout simplement des requêtes sont envoyées vers le maître, mais mettent trop de temps à s'exécuter, ce qui explique que pgpool n'en envoie pas d'autres avant que les premières ne soient terminées. Les performances du serveur maître restent quand même assez surprenantes.
Julien.
https://rjuju.github.io/
En ligne
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
Dernière modification par yassine199105 (20/08/2014 11:05:59)
Hors ligne
Comment faites-vous les rsync ? Instances esclaves éteintes et entre pg_start_backup() et pg_stop_backup() sur le maître ?
Julien.
https://rjuju.github.io/
En ligne
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 ?
Dernière modification par yassine199105 (20/08/2014 14:29:25)
Hors ligne
Le start/stop backup est obligatoire si l'instance maître est en route durant la copie, mais vous faites une copie à froid, ce n'est donc pas à faire.
Quel est le message d'erreur exact dont vous parliez ?
Julien.
https://rjuju.github.io/
En ligne
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/C7000078
Voila 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 principal
Et 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
Dernière modification par yassine199105 (20/08/2014 15:49:54)
Hors ligne
Cela indique un problème dans la lecure des journaux de transaction. Je suppose que les esclaves parviennent à continuer la réplication depuis la streaming replication. Avez-vous désactivé le fsync ?
Julien.
https://rjuju.github.io/
En ligne
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.
Dernière modification par yassine199105 (20/08/2014 16:04:45)
Hors ligne
Du rsync depuis le maître vers les esclaves. Les données des transactions ne sont pas synchronisées dans les journaux de transaction, du coup ceux-ci sont totalement incohérents. Vous pouvez exclure le répertoire pg_xlog de votre rsync, cela devrait résoudre le problème (il est d'ailleurs en général obligatoire de le faire).
Mais vous essayez de faire des tests de montée en charge avec le paramètre fsync à off ? C'est totalement sans intérêt, à moins que vous pouviez vous permettre de perdre toutes vos données.
Julien.
https://rjuju.github.io/
En ligne
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.
Hors ligne
Oui, le fsync permet de garantir l'intégrité des données même en cas de crash. Sans cela, le risque de corruption est très important.
Julien.
https://rjuju.github.io/
En ligne
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.
Hors ligne
Elles sont synchronisées par défaut lors du COMMIT, sous réserve que le fsync soit à on (et que le système respecte les demande de fsync ben évidemment).
Julien.
https://rjuju.github.io/
En ligne
Je vous remercie pour toutes ces précisions qui m'ont beaucoup aider à voir plus clair sur ce sujet.
Hors ligne
Pages : 1