Re: vacuum full et hot standby WAL stream: FATAL

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 <michael(dot)paquier(at)gmail(dot)com> a écrit :

> 2016-05-25 2:31 GMT-07:00 Stéphane Schildknecht
> <stephane(dot)schildknecht(at)postgres(dot)fr>:
>> 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 (pgsql-fr-generale(at)postgresql(dot)org)

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