Jeśli chodzi o przechowywanie archiwów, możesz wybrać funkcję rejestrowania skompresowanych archiwów w PostgreSQL.
„archive_command(string)” w $PGDATA/postgresql.conf , jest jak polecenie powłoki do wykonania tego, co zostało przekazane w sekcji ciągu w celu skopiowania wypełnionego pliku źródłowego (segment pliku WAL w $PGDATA/pg_xlog ) do miejsca docelowego (LOKALIZACJA ARCHIWUM ). „ciąg” może być czymś w rodzaju skryptu powłoki (wsadowego w systemie Windows), narzędzi do kompresji systemu operacyjnego i specjalnego narzędzia pg_compresslog. W systemie Windows cmd.exe wykona polecenie przekazane w archive_command „string”.
Ponieważ aplikujemy na platformę Windows, wstępne wymagania to:
- Katalog archiwum powinien mieć pełny dostęp użytkownika postgres. („C:Program FilesPostgreSQL9.2archives” w moim przypadku)
- Narzędzie GZIP w wersji dla systemu Windows. Chociaż istnieje wiele dobrych narzędzi do kompresji wariantów systemu Windows, wybrałem gzip, ponieważ jest obsługiwany zarówno w systemie Linux, jak i Windows.
- Gzip.exe powinien mieć dostęp do użytkownika Postgres, a także do PATH. („C:Program FilesGnuWin32bin” w moim przypadku).
Zakładając, że wszystkie wymagania wstępne są spełnione, następnym krokiem powinna być edycja pliku $PGDATA/postgresql.conf i zmiana parametrów związanych z archiwizacją oraz ponowne uruchomienie klastra:
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)
Zgodnie z dokumentacją PG, dokonano zmian i ponownie uruchomiono klaster, spodziewając się, że od tego momentu moje archiwa zostaną skompresowane. Spójrzmy na logi:
2013-07-26 16:07:22 IST LOG:polecenie archiwum nie powiodło się z kodem zakończenia 1
2013-07-26 16:07:22 IST SZCZEGÓŁY:Polecenie archiwum nie powiodło się:"""C :Program FilesGnuWin32bingzip.exe" -1 <"pg_xlog
