Re: vacuum full et hot standby WAL stream: FATAL

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 <guillaume(at)lelarge(dot)info> a écrit :

> Le 27 mai 2016 4:33 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> 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 <guillaume(at)lelarge(dot)info> a écrit :
>>
>>> 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)
>>
>>
>>
>>
>>
>> --
>> 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)