Re: vacuum full et hot standby WAL stream: FATAL

On 25/05/2016 11:09, Guillaume Lelarge wrote:
> Le 25 mai 2016 à 10:42, Stéphane Schildknecht
> <stephane(dot)schildknecht(at)postgres(dot)fr <mailto:stephane(dot)schildknecht(at)postgres(dot)fr>>
> a écrit :
>
> Bonjour,
>
> On 25/05/2016 08:36, Guillaume Lelarge wrote:
> > Le 25 mai 2016 12:01 AM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr>
> > <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr>>> a
> écrit :
> >>
> >> il semblerait indispensable de mettre en place l’archivage des journaux en
> > plus de la streaming réplication
> >> la ceinture suffit pas faut aussi les bretelles
> >>
> >
> > Oui, pour toutes les versions qui ne disposent pas encore des slots de
> > réplication. Avec les slots de réplication, l'archivage n'est plus nécessaire.
>
> Je me permets d'ajouter un petit bémol à cette affirmation.
>
> Si le secondaire est indisponible, l'utilisation de slot de réplication conduit
> à la rétention des fichiers WAL sur le primaire.
>
> Et cela *jusqu'à* la reconnexion du secondaire. Si le secondaire ne revient pas
> assez rapidement ("rapidement" étant fonction de l'activité sur le serveur
> principal), on peut arriver à la saturation de la partition de stockage des
> pg_xlog sur le primaire, et à l'arrêt du serveur principal.
>
> Donc, non, l'utilisation de slots de réplication ne remplace pas l'archivage
> des WAL.
>
>
> Tu as le même problème avec l'archivage. Si l'archivage ne fonctionne pas,
> accumulation des journaux sur le maître...
>

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.

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.

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.

En résumé :
Dans le cas des bases de données, le sirop Typhon n'existe pas.
Différentes méthodes sont applicables, mais en l'absence de supervision, aucune
n'est valable.

S.
--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, support et formation
01.79.72.57.75

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