pg_archivecleanup is designed to be used as an archive_cleanup_command to clean up WAL file archives when running as a standby server (see Section 27.2). pg_archivecleanup can also be used as a standalone program to clean WAL file archives.
PostgreSQL WAL Retention And Clean Up: Pg archivecleanup
pg_archivecleanup did not work with %r option, then I got the archive name by searching in pg_controldata latest checkpoint's REDO WAL file and deleted the logs, but then one replica stopped with the error
Criteria No. 3 needs to be taken care of by Standby because only Standby knows what the current restart point is. Again, a built-in feature in PostgreSQL helps us for calling a cleanup shell script. A shell script can be specified for parameter archive_cleanup_command in recovery.conf. This feature can be used for calling pg_archivecleanup like:
However, things will get complicated if there is more than one standby server referring to the same archive location. One standby might be lagging behind and wants a WAL which is already cleaned by another standby. In such cases, we may have to use custom scripts/program which embeds pg_archivecleanup.
All these different criteria create a set of requirements which can be addressed by custom scripts or are already addressed by different backup solutions for PostgreSQL. If we want to implement WAL retention policies with its own logic, we may end up executing pg_archivecleanup from multiple wrapper scripts. We may also think about adding more capabilities to pg_archivecleanup for addressing custom requirements.
Luckily this is a very small, standalone, single file, (no need of postgresql server), easy to read source code with less than 400 lines. It is designed for user customization, including extensive comments. The pg_archivecleanup.c file can be located in the /src/bin/pg_archivecleanup directory. Since it is a standalone program, users with minimal C knowledge can easily customize the program. So this writeup is about the walkthrough of the code and its normal functionality.
If you have an offline server and need to remove WAL to start it you can use pg_archivecleanup if you must. It knows how to remove only WAL that isn't needed by the server its self ... but it might break your archive-based backups, streaming replicas, etc. So don't use it unless you must.
A solution that we went for, is executing pg_basebackup every night. This would create a base backup and later on we can use pg_archivecleanup to clean up all the "old" WAL files before that base using something like
pg_archivecleanup is designed to be used as an archive_cleanup_command to clean up WAL file archives when running as a standby server (see Section 26.2). pg_archivecleanup can also be used as a standalone program to clean WAL file archives.
C'est impossible. Le but de l'archivage, c'est d'archiver dès que possible. Donc dès que le journal est plein, il est archivé. Il n'y a aucun moyen de changer cela. Vous avez simplement mal configuré vos systèmes de fichiers. Celui des WAL en cours doit être suffisamment grand pour conserver les journaux avant leur archivage, et celui des WAL archivés doit être suffisamment grand pour conserver les journaux d'après votre politique de sauvegarde (et notamment la rétention souhaitée). Si vous archivez uniquement pour la réplication, vous devez utiliser l'outil pg_archivecleanup à partir du secondaire pour supprimer les journaux archivés devenus inutiles (ce qui devrait supprimer pratiquement tout).
Et en relisant ma réponse, je me dis que si vous voulez éviter la saturation du systèmes de fichiers des archives, c'est que vous avez certainement oublié de mettre en place pg_archivecleanup sur le secondaire pour qu'il supprime les archives devenues inutiles, et non pas conserver les journaux sur le primaire.
Concernant l'utilisation de pg_archivecleanup, je me suis renseigné sur le lien officiel et je ne suis pas sûr qu'il réponde à notre besoin.Nous souhaitons conserver les archive logs sur plusieurs jours pour répondre au cas par exemple où le serveur secondaire est indisponible pendant plusieurs jours (crash de la VM, soucis de réplication etc.) afin de pouvoir faire une restauration des transactions jouées sur le noeud primaire en l'absence du noeud secondaire une fois que celui-ci est de nouveau rendu disponible.Nous avons mis en place un script de purge ds le contab qui purge les archives logs de plus de 4 jours.
Votre script ne prend pas en compte le fait que le secondaire ait besoin ou non des archives. Il supprime sans distinction ceux de plus de 4 jours, donc en reprenant votre exemple, si votre secondaire est indisponible pendant plus de 4 jours, il sera impossible de le resynchroniser automatiquement. Par contre, l'intérêt de pg_archivecleanup est justement d'éviter ça. Quand il est exécuté par le secondaire, ce dernier lui indique la première archive dont il a encore besoin, et pg_archivecleanup supprimera toutes les archives plus anciennes que cette archive. pg_archivecleanup est exactement ce dont vous avez besoin, et votre script est exactement ce que vous devez éviter.
En relisant le code de notre script de purge, je me rends compte qu'il utilisait déjà la commande pg_archivecleanup.Le script est schedulé pour être lancé deux fois par jour par le crontab Linux. 2ff7e9595c
Comments