Re: vacuum full et hot standby WAL stream: FATAL

hello
toujours pas de retour , test en charge ce weekend donc retour lundi  
(wal_keep_segments = 4000)

question replication :
les exigences de mon système sont 0 perte de données entre primaire et  
secondaire :
a t'on un retour d'expérience sur ce type d'exigence de haute  
disponibilité avec postgresql , car
d’après ce que j'ai cru comprendre la réplication par streaming est  
relativement jeune chez postgresql ?

cordialement





CRUMEYROLLE Pierre <[email protected]> a écrit :

> ok merci pour ces précisions
> dans l’immédiat j'ai tenté un wal_keep_segments = 4000 pour voir
> réponse demain
>
>
> Michael Paquier <[email protected]> a écrit :
>
>> 2016-05-25 2:31 GMT-07:00 Stéphane Schildknecht
>> <[email protected]>:
>>> Effectivement, ma réponse n'était peut-être pas assez complète.
>>> Je n'ai pas dit que la solution était parfaite. En l'absence de  
>>> supervision,
>>> toute solution est imparfaite, puisque faillible.
>>>
>>> Lorsque l'on met en place une solution de réplication, il est  
>>> *impératif* de
>>> surveiller l'espace disque sur le serveur principal, et l'activité des WAL.
>>>
>>> Pour s'assurer que le nœud secondaire soit toujours en mesure de  
>>> repartir, on
>>> peut :
>>> - utiliser le paramètre wal_keep_segments ;
>>> - utiliser les slots de réplication ;
>>> - utiliser l'archivage des WAL.
>>>
>>> Il n'y a pas de solution universelle, et les trois possibilités ne  
>>> s'exclut pas.
>>>
>>> Dans tous les cas, il faut surveiller l'activité et l'occupation  
>>> des disques.
>>>
>>> Le paramètre wal_keep_segments n'est pas forcément suffisant, il  
>>> reste possible
>>> de perdre des WAL. Mais il permet de s'assurer qu'on ne saturera pas la
>>> partition du fait de l'empilement de WAL non consommés.
>>
>> L'archivage des WAL représente un avantage en comparaison des slots de
>> réplication: ils peuvent être compressés, permettant de garder plus
>> d'histoire pour le même montant d'espace.
>>
>>> Les slots de réplication ne sont pas une solution idéale, ils ne permettent
>>> pas, par exemple de prévoir de faire du PITR. Le risque est réel  
>>> également de
>>> ne jamais purger les WAL et de saturer les disques.
>>
>> Amen.
>>
>>> L'archivage, en soi, n'est pas suffisant, puisqu'en l'absence de  
>>> surveillance
>>> des disques sur le secondaire, on peut aussi saturer la partition  
>>> WAL sur le
>>> primaire. Ou simplement si l'archivage ne peut s'effectuer. Mais  
>>> il permet de
>>> déporter le stockage des WAL et de permettre à un nœud secondaire  
>>> de prendre
>>> plus de retard et de le rattraper sans forcément impacter le primaire.
>>
>> Celà dépend grandement où se situe la priorité du cluster: le maître
>> peut-il être mis à terre pendant quelques minutes? Ou non?
>> --
>> Michael
>>
>>
>> --
>> Envoi via la liste pgsql-fr-generale ([email protected])




--
Envoi via la liste pgsql-fr-generale ([email protected])