Re: vacuum full et hot standby WAL stream: FATAL

Le 27 mai 2016 4:50 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> 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.
>

Il faut que la table soit nettoyée suffisamment fréquemment avec un vacuum
standard pour ne pas avoir besoin du full.

Avec certaines activités, ce n'est pas suffisant malheureusement.

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

Guillaume