Re: vacuum full et hot standby WAL stream: FATAL

Le 27 mai 2016 3:56 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> 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 <cedric(at)2ndquadrant(dot)com> 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 (pgsql-fr-generale(at)postgresql(dot)org)
>
>
>
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)