Posiadanie regularnych kopii zapasowych samej bazy danych PostgreSQL nie jest wystarczające do odzyskiwania po awarii — musisz upewnić się, że pliki kopii zapasowej są dostępne i zdrowe, jeśli i kiedy jest to wymagane do procedury przywracania. Czytaj dalej, aby zobaczyć kilka przykładów, jak skonfigurować automatyczne testowanie kopii zapasowych PostgreSQL.
Kopie zapasowe utworzone przy użyciu pg_basebackup
pg_basebackup kopie zapasowe zawierają cały katalog danych dla klastra bazy danych. Ten katalog jest zwykle spakowany w archiwum, czasami z dodatkowym archiwum dla plików WAL, które zostały utworzone od początku tworzenia kopii zapasowej.
Aby przetestować taką pg_basebackup tarball, najpierw rozpakuj go do pustego katalogu. Jeśli istnieje osobna paczka plików WAL, rozpakuj ją do pg_wal katalog w nowym katalogu:
$ mkdir backup-test
$ cd backup-test
$ tar --no-same-owner xvf /path/to/base.tar.gz
$ mkdir -p pg_wal
$ cd pg_wal
$ tar --no-same-owner xvf /path/to/pg_wal.tar.gzMożesz teraz uruchomić proces serwera PostgreSQL dla tego katalogu:
$ pg_ctl -D path/to/backup-test start(Uwaga:pg_ctl to narzędzie wiersza poleceń zawarte w standardowej dystrybucji Postgres. Jest dostępne wszędzie tam, gdzie sam Postgres jest, podobnie jak inne dołączone narzędzia, takie jak psql i pg_dump .Dowiedz się więcej o pg_ctl tutaj.)
Jeśli na tym komputerze jest już zainstalowany/działający serwer PostgreSQL, prawdopodobnie będziesz chciał uruchomić na porcie innym niż domyślny 5432:
$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" startJeśli do tej pory wszystko się udało, będziesz chciał sprawdzić, czy dane w przywróconej bazie danych są prawidłowe. Jeśli masz zautomatyzowane skrypty testowe do uruchomienia na twojej bazie danych, teraz jest dobry moment, aby uruchomić przynajmniej mały zestaw tych testów na przywróconej bazie danych. Jeśli nie, możesz zhakować kilka szybkich testów za pomocą psql:
$ psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"Powyższe polecenie wykonuje proste zapytanie do tabeli, która powinna istnieć. Kod wyjścia z psql powinien powiedzieć, czy zapytanie się powiodło, czy nie. Oczywiście możesz uruchamiać bardziej złożone zapytania lub uruchomić plik .sql, a nawet oddzielny testscript, który połączy się z tą bazą danych i uruchomi testy.
Po zakończeniu testów możesz zatrzymać proces serwera Postgres za pomocą:
$ pg_ctl -D path/to/backup-test stopI wyczyść cały wyodrębniony katalog klastra bazy danych:
$ rm -rf path/to/backup-testOto jak to wygląda po złożeniu:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest backup
# TODO: copy out base.tar.gz and pg_wal.tar.gz of latest backup
# create a directory to work in
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
mkdir $BACKUP_DIR
# unpack the backup archives
tar -C $BACKUP_DIR --no-same-owner xvf /path/to/base.tar.gz
mkdir -p $BACKUP_DIR/pg_wal
tar -C $BACKUP_DIR/pg_wal --no-same-owner xvf /path/to/pg_wal.tar.gz
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/base.tar.gz /path/to/pg_wal.tar.gzKopie zapasowe utworzone przy użyciu pg_dump
pg_dump narzędzie (dokumenty) może być również używane do tworzenia kopii zapasowych – jest to bardziej elastyczne, ponieważ możesz opcjonalnie wybrać bazę danych/schemat/tabele, które chcesz wykonać w kopii zapasowej, w przeciwieństwie do pg_basebackup który jest procesem typu wszystko albo nic.
Z pg_dump , możesz wygenerować pojedynczy plik .sql skrypt lub plik binarny .pgdmp plik zawierający wszystkie dane (i opcjonalnie także instrukcje DDL do tworzenia tabel/indeksów itp.). Aby przywrócić taki plik, musisz połączyć się z serwerem livedatabase i uruchomić polecenia SQL w pliku .sql/.pgdmp. Chociaż możesz używać zwykłego psql aby uruchomić plik .sql, musisz użyć pg_restore polecenie (docs), aby uruchomić plik .pgdmp.
Aby przetestować takie kopie zapasowe, najpierw pobieramy plik, a następnie tworzymy nowy, pusty klaster bazy danych:
$ rm -rf path/to/backup-test
$ pg_ctl -D path/to/backup-test initdbi uruchom na nim serwer PostgreSQL, nasłuchując na porcie 6000 jak poprzednio:
$ pg_ctl -D path/to/backup-test -o "-p 6000 -k /tmp" startMożliwe jest wygenerowanie pg_dump pliki, które są w pełni samowystarczalne, ale istnieje również możliwość ich wygenerowania, aby tak nie było. Dlatego, w zależności od sposobu wygenerowania zrzutu, mogą być wymagane pewne kroki konfiguracji:
- utwórz bazę danych
- tworzenie tabel, indeksów itp.
- nadaj uprawnienia
Gdy to zrobisz, możesz użyć psql lub pg_restore aby przywrócić dane do życia:
# for .sql files
$ psql -p 6000 -h /tmp -v ON_ERROR_STOP=1 -1 -b -f path/to/dump.sql
# for .pgdmp files
$ pg_restore -p 6000 -h /tmp -d mydb -C -1 -f path/to/dump.pgdmpTak jak poprzednio, w tym momencie można przeprowadzić testy w celu zapewnienia poprawności przechowywanych danych.
Oto jak to wygląda, wszystko razem wzięte:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest dump
# TODO: copy out the dump.sql or dump.pgdmp of latest backup
# create an empty database cluster
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
pg_ctl -D $BACKUP_DIR initdb
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# TODO: perform any specific setup steps here
# restore the file, .sql:
psql -p 6000 -h /tmp -v ON_ERROR_STOP=1 -1 -b -f path/to/dump.sql
# or .pgdmp:
pg_restore -p 6000 -h /tmp -d mydb -C -1 -f path/to/dump.pgdmp
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/dump.*Uważaj na wyzwalacze
Podczas przywracania pg_dump kopia zapasowa, dane są umieszczane w tabelach, podobnie jak robi to aplikacja. Jeśli masz wyzwalacze, które łączą się z usługami zewnętrznymi w celu powiadomienia o wstawieniu wierszy, najlepiej wyłączyć je podczas procedury przechowywania.
Podczas wywoływania pg_dump aby emitować pliki sql, możesz użyć opcji --disable-triggers powiedzieć pg_dump aby wygenerować skrypt wyłączający wyzwalacze podczas wstawiania.
Podczas wywoływania pg_restore w bazie danych, która ma już wyzwalacze, możesz użyć --disable-triggers w pg_restore aby osiągnąć ten sam efekt.
Testowanie PITR
Odzyskiwanie punktu w czasie (PITR) w Postgresie opiera się na pełnej kopii zapasowej wykonanej przy użyciu pg_basebackup i sekwencję plików WAL od tego momentu do momentu, w którym chcesz odzyskać dane. Dlatego testowanie PITR obejmuje testowanie pełnej kopii zapasowej, a także kolejnych plików WAL.
W przypadku automatycznego testowania kopii zapasowych nie mamy określonego celu odzyskiwania. Wszystkie zarchiwizowane pliki WAL począwszy od ostatniej kopii zapasowej aż do najnowszych powinny zostać przetestowane. Najłatwiej to przetestować, wykonując te same czynności, co w przypadku pg_basebackup metoda testowa, z tylko jednym dodatkowym krokiem. Po rozpakowaniu najnowszej kopii zapasowej pobierz wszystkie istotne i dostępne pliki WAL i umieść je w pg_wal przed uruchomieniem serwera Postgres. W szczególności:
#!/bin/bash
# exit immediately if any step fails
set -eo pipefail
# fetch the latest backup
# TODO: copy out base.tar.gz and pg_wal.tar.gz of latest backup
# create a directory to work in
BACKUP_DIR=/tmp/backup-test
rm -rf $BACKUP_DIR
mkdir $BACKUP_DIR
# unpack the backup archives
tar -C $BACKUP_DIR --no-same-owner xvf /path/to/base.tar.gz
mkdir -p $BACKUP_DIR/pg_wal
tar -C $BACKUP_DIR/pg_wal --no-same-owner xvf /path/to/pg_wal.tar.gz
# --> this is the new extra step <--
# TODO: fetch all WAL files from the WAL archive since the last
# backup, and place them in $BACKUP_DIR/pg_wal
# start a new Postgres server for the cluster on port 6000
pg_ctl -D $BACKUP_DIR -o "-p 6000 -k /tmp" start
# perform a simple test
psql -p 6000 -d mydb -o /dev/null -c "select * from users limit 1"
# shutdown the server
pg_ctl -D $BACKUP_DIR stop
# cleanup the files
rm -rf $BACKUP_DIR /path/to/base.tar.gz /path/to/pg_wal.tar.gzPowinno to zweryfikować, czy zarówno ostatnia kopia zapasowa, jak i kolejne pliki WAL są dobre, aby można je było wykorzystać do PITR w razie potrzeby.
