Remise à zéro des segments WAL dans Postgres

Nous avons une base de données Postgres à volume relativement faible avec un archivage continu configuré pour compresser chaque segment WAL et l'envoyer à S3. Parce que c'est un système à faible volume, il frappe archive_timeouttoutes les 10 minutes environ et archive le segment WAL le plus inutilisé, qui se compressait très bien car il s'agissait principalement de zéros.

Cependant, Postgres recycle ses segments WAL pour éviter le coût d'allocation de nouveaux fichiers à chaque commutateur WAL, ce qui est utile dans une situation de forte charge, mais cela signifie qu'après une explosion d'activité plus lourde que la normale, nos fichiers de segments WAL sont maintenant pleins de déchets provenant des segments précédents et ne compressent pas très bien du tout. Nous stockons beaucoup de copies de toutes ces ordures.

Existe-t-il un moyen de réduire la quantité d'espace que nous utilisons pour conserver nos archives WAL? Quelques possibilités sous-optimales:

1. Empêchez Postgres de recycler les segments WAL d'une manière ou d'une autre, de sorte qu'il commence à chaque fois avec un fichier mis à zéro. Les documents n'indiquent pas qu'il existe une option pour cela, mais je l'ai peut-être manquée.

2. Demandez à Postgres de mettre à zéro le fichier de segment WAL lorsqu'il commence / finit de l'utiliser. Encore une fois, les documents ne semblent pas suggérer que cela soit possible.

3. Mettez à zéro en externe ou supprimez certains des fichiers de segment WAL lorsqu'ils ne sont pas utilisés. Existe-t-il un moyen sûr de déterminer de quels fichiers il s'agit?

4. Mettez à zéro la partie inutilisée du segment avant de l'archiver à l'aide de la sortie de pg_xlogdumppour trouver où commence le courrier indésirable. Possible, bien que je n'en ai pas envie. Au moins, en faisant cela dans la commande archive, vous pouvez être sûr que Postgres ne va pas réutiliser le fichier.

5. Archivez uniquement la partie utilisée du fichier de segment, encore une fois en interprétant la sortie de pg_xlogdumpquelque manière, puis remplissez-la avec des zéros pendant la restauration. Cela semble également possible, bien que je ne l'aime pas vraiment.

À partir de la version 9.4, il remet à zéro automatiquement la fin du fichier WAL. (En fait, il s'agit principalement de zéro, il y a des en-têtes de bloc qui ne sont pas mis à zéro, mais le résultat est toujours très compressible).

Dans la version 9.2, il existe un programme nommé que pg_clearxlogtailvous pouvez utiliser. Vous pouvez l'ajouter dans votre archive_command avant l'étape de compression.

Si vous utilisez 9.3, vous n'avez pas de chance.

Notez que les points de contrôle ne provoquent pas intrinsèquement des changements de fichier journal. C'est probablement archive_timeout qui est à l'origine des commutateurs.