Re: vacuum full et hot standby WAL stream: FATAL

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