Re: vacuum full et hot standby WAL stream: FATAL
Michael Paquier <[email protected]>
| Newsgroups | gmane.comp.db.postgresql.french |
|---|---|
| Message-ID | <CAB7nPqRh9bcN2CapxO_1xLK8D8zxFWLMge_VO4QqUb6X8Sgr2w@mail.gmail.com> |
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])