Re: vacuum full et hot standby WAL stream: FATAL

si j'en crois l'extract ci dessous
réplication synchrone => il n'y a pas de risque de perte de données
au moment d'une bascule du maître ;
réplication asynchrone =>
En cas d'arrêt brutal (crash) du serveur maître, les données peuvent
ne pas avoir été complètement synchronisées avec les serveurs
esclaves. Cela occasionne une perte de données, généralement faible
mais toujours très désagréable.

d'ou le choix réplication synchrone car perte de données au moment
d'une bascule du maître interdite

extract from
http://www.dalibo.org/glmf131_mise_en_place_replication_postgresl_9.0_1

La deuxième particularité concerne le côté synchrone ou non de la
réplication. Une réplication synchrone fonctionne de la façon suivante
: une transaction n'est pas considérée validée (pas de COMMIT) tant
que tous les serveurs n'ont pas validé cette transaction. Il y a
plusieurs intérêts à ça :

il n'y a pas de risque de perte de données au moment d'une
bascule du maître ;
le résultat d'une requête est cohérent quelque soit le serveur
interrogé dans le cadre d'un cluster en répartition de charge.

Le soucis majeur de ce type de réplication est les performances (ou
plutôt les contre-performances). En effet, il faut bien comprendre que
pour chaque transaction modifiant des données, il ne suffit pas qu'un
serveur enregistre cette information. Il faut que tous l'aient
enregistré. Cela va ajouter une surcharge plus ou moins importante
suivant la solution choisie. Des solutions asynchrones existent. Elles
sont généralement plus performantes. Le serveur qui fait l'écriture
renvoie au client le fait que l'enregistrement s'est bien passé et se
charge un peu après d'envoyer l'information sur les données modifiées
aux autres serveurs. En cas d'arrêt brutal (crash) du serveur maître,
les données peuvent ne pas avoir été complètement synchronisées avec
les serveurs esclaves. Cela occasionne une perte de données,
généralement faible mais toujours très désagréable.
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.
>
>
>
> 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)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)