pg_stat_wait timeout

yassine199105 · 14/08/2014 11:38:02

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)

gleu · 14/08/2014 12:03:33

Le message du wait timeout indique en effet un système disque très lent. vmstat permettrait de savoir ce qu'il en ait.

yassine199105 · 14/08/2014 13:13:19

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)

rjuju · 14/08/2014 13:29:45

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.

yassine199105 · 14/08/2014 15:00:31

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

rjuju · 14/08/2014 20:28:01

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 ?

yassine199105 · 18/08/2014 15:05:35

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.

rjuju · 19/08/2014 00:02:29

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.

yassine199105 · 19/08/2014 10:03:58

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)

rjuju · 19/08/2014 18:02:38

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.

yassine199105 · 20/08/2014 10:57:33

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)

rjuju · 20/08/2014 11:41:13

Comment faites-vous les rsync ? Instances esclaves éteintes et entre pg_start_backup() et pg_stop_backup() sur le maître ?

yassine199105 · 20/08/2014 12:07:12

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)

rjuju · 20/08/2014 15:35:14

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 ?

yassine199105 · 20/08/2014 15:42:08

 
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)

rjuju · 20/08/2014 15:54:11

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 ?

yassine199105 · 20/08/2014 16:02:43

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)

rjuju · 20/08/2014 16:22:34

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.

yassine199105 · 20/08/2014 16:27:08

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.

rjuju · 20/08/2014 16:32:04

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.

yassine199105 · 25/08/2014 09:43:32

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.

rjuju · 25/08/2014 17:01:08

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

yassine199105 · 25/08/2014 17:13:12

Je vous remercie pour toutes ces précisions qui m'ont beaucoup aider à voir plus clair sur ce sujet.

#1 14/08/2014 11:38:02

pg_stat_wait timeout

#2 14/08/2014 12:03:33

Re : pg_stat_wait timeout

#3 14/08/2014 13:13:19

Re : pg_stat_wait timeout

#4 14/08/2014 13:29:45

Re : pg_stat_wait timeout

#5 14/08/2014 15:00:31

Re : pg_stat_wait timeout

#6 14/08/2014 20:28:01

Re : pg_stat_wait timeout

#7 18/08/2014 15:05:35

Re : pg_stat_wait timeout

#8 19/08/2014 00:02:29

Re : pg_stat_wait timeout

#9 19/08/2014 10:03:58

Re : pg_stat_wait timeout

#10 19/08/2014 18:02:38

Re : pg_stat_wait timeout

#11 20/08/2014 10:57:33

Re : pg_stat_wait timeout

#12 20/08/2014 11:41:13

Re : pg_stat_wait timeout

#13 20/08/2014 12:07:12

Re : pg_stat_wait timeout

#14 20/08/2014 15:35:14

Re : pg_stat_wait timeout

#15 20/08/2014 15:42:08

Re : pg_stat_wait timeout

#16 20/08/2014 15:54:11

Re : pg_stat_wait timeout

#17 20/08/2014 16:02:43

Re : pg_stat_wait timeout

#18 20/08/2014 16:22:34

Re : pg_stat_wait timeout

#19 20/08/2014 16:27:08

Re : pg_stat_wait timeout

#20 20/08/2014 16:32:04

Re : pg_stat_wait timeout

#21 25/08/2014 09:43:32

Re : pg_stat_wait timeout

#22 25/08/2014 17:01:08

Re : pg_stat_wait timeout

#23 25/08/2014 17:13:12

Re : pg_stat_wait timeout

Pied de page des forums

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux