Re: vacuum full et hot standby WAL stream: FATAL

si j'en crois l'extract ci dessous
réplication synchrone  => il n'y a pas de risque de perte de données  
au moment d'une bascule du maître ;
réplication asynchrone  =>
En cas d'arrêt brutal (crash) du serveur maître, les données peuvent  
ne pas avoir été complètement synchronisées avec les serveurs  
esclaves. Cela occasionne une perte de données, généralement faible  
mais toujours très désagréable.

d'ou le choix réplication synchrone  car perte de données au moment  
d'une bascule du maître interdite

extract from  
http://www.dalibo.org/glmf131_mise_en_place_replication_postgresl_9.0_1

  La deuxième particularité concerne le côté synchrone ou non de la  
réplication. Une réplication synchrone fonctionne de la façon suivante  
: une transaction n'est pas considérée validée (pas de COMMIT) tant  
que tous les serveurs n'ont pas validé cette transaction. Il y a  
plusieurs intérêts à ça :

     il n'y a pas de risque de perte de données au moment d'une  
bascule du maître ;
     le résultat d'une requête est cohérent quelque soit le serveur  
interrogé dans le cadre d'un cluster en répartition de charge.

Le soucis majeur de ce type de réplication est les performances (ou  
plutôt les contre-performances). En effet, il faut bien comprendre que  
pour chaque transaction modifiant des données, il ne suffit pas qu'un  
serveur enregistre cette information. Il faut que tous l'aient  
enregistré. Cela va ajouter une surcharge plus ou moins importante  
suivant la solution choisie. Des solutions asynchrones existent. Elles  
sont généralement plus performantes. Le serveur qui fait l'écriture  
renvoie au client le fait que l'enregistrement s'est bien passé et se  
charge un peu après d'envoyer l'information sur les données modifiées  
aux autres serveurs. En cas d'arrêt brutal (crash) du serveur maître,  
les données peuvent ne pas avoir été complètement synchronisées avec  
les serveurs esclaves. Cela occasionne une perte de données,  
généralement faible mais toujours très désagréable.
CRUMEYROLLE Pierre <[email protected]> a écrit :

> en effet tout se supervise, de plus un réseau pourri ça s'améliore,  
> ça se sécurise, les disques aussi, la mémoire ça se gonfle etc ...
>
> par contre je n'ai pas trouvé comment m'affranchir du vacuum full ,  
> si ya une solution je suis preneur.
>
>
>
> Guillaume Lelarge <[email protected]> a écrit :
>
>> Le 27 mai 2016 4:33 PM, "CRUMEYROLLE Pierre" <[email protected]> a
>> écrit :
>>>
>>> mon exigence est : toutes les données committées sur le serveur primaire
>> doivent se retrouvées sur le serveur secondaire
>>>
>>
>> Dit comme ça, une réplication asynchrone suffit. Toute donnée commitée est
>> envoyée à l'esclave.
>>
>>> j'ai jamais dit que Le vacuum full avait  planté PostgreSQL mais par
>> effet domino le vacuum full plante la réplication.
>>>
>>
>> Oui, tout comme plein d'autres trucs. D'où le besoin d'un système de
>> supervision.
>>
>>> Guillaume Lelarge <[email protected]> a écrit :
>>>
>>>> Le 27 mai 2016 3:56 PM, "CRUMEYROLLE Pierre" <[email protected]>
>> a
>>>> écrit :
>>>>>
>>>>>
>>>>> hello
>>>>> rectification : à condition que le vacuum full ne la  plante pas
>>>>
>>>>
>>>> Le vacuum full n'a pas planté PostgreSQL. La mauvaise configuration de
>>>> PostgreSQL a engendré un problème au niveau de l'esclave. Ce n'est pas la
>>>> même chose :-) Notamment le maître est toujours debout.
>>>>
>>>>> "En général il y a peu d'intérêt à ce que toutes les transactions soient
>>>>
>>>> répliquées de manière synchrone" => alors pourquoi inventer une
>> réplication
>>>> synchrone ?
>>>>
>>>> Je suis d'accord avec Cédric que décider d'utiliser une réplication
>>>> synchrone ne se fait pas à la légère. Ce n'est utile que dans très peu de
>>>> cas, ce qui explique qu'on le voit beaucoup moins fréquemment que des
>>>> réplications asynchrones.
>>>>
>>>>> cordialement
>>>>>
>>>>>
>>>>> Cédric Villemain <[email protected]> a écrit :
>>>>>
>>>>>
>>>>>>> on peut s'appuyer sur la réplication synchrone => a condition qu'elle
>> ne
>>>>>>> plante pas
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alors là, je reste dubitatif. Que voulez-vous dire?
>>>>>>
>>>>>> En général il y a peu d'intérêt à ce que toutes les transactions soient
>>>>>> répliquées de manière synchrone, et en général on met en œuvre
>> plusieurs
>>>>>> serveurs secondaires pour garantir la disponibilité.
>>>>>>
>>>>>> L'impact sur les performances peut être sensible et l'application doit
>>>>>> gérer le fait qu'elle utilise la réplication synchrone (ou pour le
>> moins
>>>>>> elle doit correctement appréhender les finesses du standard SQL sur le
>>>>>> sujet).
>>>>>>
>>>>>> Cela ne se décide pas à la légère.
>>>>>>
>>>>>> --
>>>>>> Cédric Villemain +33 (0)6 20 30 22 52
>>>>>> http://2ndQuadrant.fr/
>>>>>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Envoi via la liste pgsql-fr-generale ([email protected])
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Envoi via la liste pgsql-fr-generale ([email protected])
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Envoi via la liste pgsql-fr-generale ([email protected])
>
>
>
>
> --
> Envoi via la liste pgsql-fr-generale ([email protected])




--
Envoi via la liste pgsql-fr-generale ([email protected])