Re: vacuum full et hot standby WAL stream: FATAL

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