From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Stéphane Schildknecht <stephane(dot)schildknecht(at)postgres(dot)fr> |
Cc: | Guillaume Lelarge <guillaume(at)lelarge(dot)info>, pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org> |
Subject: | Re: vacuum full et hot standby WAL stream: FATAL |
Date: | 2016-05-25 16:22:24 |
Message-ID: | CAB7nPqRh9bcN2CapxO_1xLK8D8zxFWLMge_VO4QqUb6X8Sgr2w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | CRUMEYROLLE Pierre | 2016-05-25 20:21:33 | Re: vacuum full et hot standby WAL stream: FATAL |
Previous Message | Stéphane Schildknecht | 2016-05-25 11:33:29 | Re: vacuum full et hot standby WAL stream: FATAL |