Si le stockage des archives est un problème, vous pouvez choisir la fonctionnalité de journalisation des archives compressées dans PostgreSQL.
"archive_command(string)" dans $PGDATA/postgresql.conf , est comme une commande shell pour exécuter ce qui est passé dans la section de chaîne pour copier le fichier source terminé (segment de fichier WAL dans $PGDATA/pg_xlog ) à destination(EMPLACEMENT D'ARCHIVE ). "chaîne" peut être quelque chose comme script shell (batch dans Windows) lui-même, utilitaires de compression du système d'exploitation et un outil spécial pg_compresslog. Sous Windows, cmd.exe exécutera la commande passée dans archive_command "string".
Puisque nous postulons sur la plateforme Windows, les pré-requis sont :
- Le répertoire d'archivage doit avoir un accès utilisateur postgres complet. ("C:Program FilesPostgreSQL9.2archives" dans mon cas)
- Utilitaire GZIP version Windows. Bien qu'il existe de nombreux bons utilitaires de compression de variantes Windows, j'ai choisi gzip car il est pris en charge à la fois sur Linux et Windows.
- Gzip.exe doit avoir accès à l'utilisateur Postgres et également au PATH. ("C:Program FilesGnuWin32bin" dans mon cas).
En supposant que tous les prérequis sont en place et que la prochaine étape devrait être de modifier le fichier $PGDATA/postgresql.conf et de modifier les paramètres liés à l'archivage et de redémarrer le cluster :
wal_level=archive
archive_mode=on
archive_command = '"C:\Program Files\GnuWin32\bin\gzip.exe -1 " < "%p" > "C:\Program Files\PostgreSQL\9.2\archives\%f.gz"'
c:Program FilesPostgreSQL9.2bin>pg_ctl.exe -D ..data start (You can also start from services.msc)
Selon la documentation PG, des modifications ont été apportées et le cluster a redémarré, en anticipant à partir de maintenant mes archives seront compressées. Regardons les journaux :
2013-07-26 16:07:22 IST LOG :la commande d'archivage a échoué avec le code de sortie 1
2013-07-26 16:07:22 IST DETAIL :la commande d'archivage a échoué :"""C :Program FilesGnuWin32bingzip.exe" -1 <"pg_xlog
