W PostgreSQL, Backup &Recovery jest bardzo przyjazny dla użytkownika w porównaniu z innymi bazami danych. Wielu z nich się na to nie zgodzi, ok, nie wdawajmy się w debatę. Jeśli chodzi o kopie zapasowe, PostgreSQL nie obsługuje INCREMENTAL BACKUP, jednak istnieją bardzo spójne narzędzia do tworzenia kopii zapasowych i obejście na poziomie systemu operacyjnego, aby osiągnąć ten cel.
Moja prezentacja obrazkowa na temat PostgreSQL Backup and Recovery daje kompletny pomysł koncepcyjny. Zaglądając do Diagramu, możesz dowiedzieć się, które kopie zapasowe mogą być użyte do przywrócenia lub odzyskania.
Logiczna kopia zapasowa
Narzędzia pg_dump, pg_restore i pg_dumpall używane do tworzenia kopii zapasowych logicznych. pg_dump i pg_restore pomogą w tworzeniu kopii zapasowych na poziomie bazy danych, poziomie schematu i poziomie tabeli. Pg_dumpall używany do zrzutu na poziomie klastra.
Obsługiwane są trzy formaty:pg_dump, zwykły format SQL, niestandardowy format i format tar. Zrzuty niestandardowe i format tar są kompatybilne z narzędziem pg_restore, podczas gdy zrzuty w formacie Plain SQL są kompatybilne z narzędziem psql do przywracania.
Poniżej znajdują się przykłady dla każdego poziomu kopii zapasowej i powiązane polecenia przywracania.
Uwaga:Ustaw wartości domyślne dla PGDATABASE, PGUSER, PGPASSWORD i PGPORT w .bash_profile (zmienne środowiskowe w systemie Windows)
Zrzut i przywracanie zwykłego formatu SQL
$ pg_dump -U username -Fp dbname > filename
or
$ pg_dump -U username dbname -f filename
or
$ pg_dump -Fp -U username dbname -f filename
For restoring use psql command
$ psql -U username -f filename dbname
or
postgres=# i SQL-file-name //in psql terminal with i option
Format niestandardowy
$ pg_dump -Fc dbname -f filename
$ pg_restore -Fc -U username -d dbname filename.dmp
Format smoły
$ pg_dump -Ft dbname -f filename
$ pg_restore -U username -d dbname filename
or
$ cat tar-file.tar | psql -U username dbname
Uwaga:Zrzuty poziomów schematu i tabel można wykonać w ten sam sposób, dodając powiązane opcje.
Zrzut na poziomie klastra:
$pg_dumpall -p portnumber > filename
For restoring use psql command
$ psql -f filename
Są najlepsze sposoby na robienie zrzutów i przywracanie metodologii. W szczególności, książka Simon Riggs i Hannu Krosing – „PostgreSQL 9 Administration Cookbook – 2010” to dobry sposób na rozpoczęcie pracy z PostgreSQL Backup and Recovery opublikowanym przez www.2ndQuadrant.com.
Fizyczna kopia zapasowa (kopia zapasowa systemu plików)
Zimna kopia zapasowa:
W przypadku zimnej kopii zapasowej jest to prosta kopia zapasowa systemu plików katalogu /data, gdy instancja Postgres nie działa, co oznacza, że aby uzyskać spójną kopię zapasową katalogu danych, serwer bazy danych powinien zostać wyłączony przed kopiowaniem. PostgreSQL zapewnia elastyczność w utrzymywaniu pg_xlog i pg_tblspce w różnych punktach montowania poprzez softlink. Podczas kopiowania katalogu /data, w tym danych miękkiego łącza, użyj poniższego polecenia.
tar czf backup.tar.gz $PGDATA
or
cp -r $PGDATA /backup/
or
rsync -a $PGDATA /wherever/data
Gorąca kopia zapasowa (kopia zapasowa online):
W trybie Hot Backup klaster będzie działał, a baza danych powinna być w trybie dziennika archiwum. Dwie funkcje systemowe powiadomią instancję o uruchomieniu i zatrzymaniu procesu Hot Backup (pg_start_backup(),pg_stop_backup()). Zanim przejdziemy do tworzenia kopii zapasowych online, omówmy tryb dziennika archiwum bazy danych, który jest obowiązkowy w przypadku kopii zapasowych online.
Włączanie archiwizacji WAL:
Najbliższe moje posty będą informować o PITR / Tunning WAL itp., obecnie przyjrzymy się Archiwizacji WAL. W systemie baz danych PostgreSQL faktyczna baza danych „zapisuje” na dysku dodatkowy plik o nazwie dziennik zapisu z wyprzedzeniem (WAL). Zawiera zapis zapisów dokonanych w systemie bazy danych. W przypadku awarii baza danych może zostać naprawiona/odzyskana z tych rekordów.
Zwykle dzienniki zapisu z wyprzedzeniem w regularnych odstępach czasu (nazywane punktami kontrolnymi) są dopasowywane do bazy danych, a następnie usuwane, ponieważ nie są już potrzebne. Możesz również użyć WAL jako kopii zapasowej, ponieważ istnieje zapis wszystkich zapisów dokonanych w bazie danych.
Koncepcja archiwizacji WAL:
Dziennik zapisu z wyprzedzeniem składa się z każdego 16 MB, które nazywane są segmentami. Pliki WAL znajdują się w katalogu pg_xlog i jest to podkatalog „katalogu danych”. Nazwy plików będą numerowane w kolejności rosnącej przez instancję PostgreSQL. Aby wykonać kopię zapasową na podstawie WAL, potrzebna jest kopia podstawowa, czyli pełna kopia zapasowa katalogu danych oraz Segmentów WAL pomiędzy kopią podstawową a datą bieżącą.
Konfigurację archiwizacji segmentów WAL można wybrać, ustawiając dwa parametry konfiguracyjne archive_command i archive_mode w pliku postgresql.conf. Przełączenie klastra w tryb dziennika archiwum wymaga RESTARTU.
archive_mode= on/off (boolean parameter)
archive_command = 'cp –i %p / Archive/Location/ f% '
Uwaga: % os dla pliku do skopiowania ze ścieżką używaną jako nazwa pliku i % f bez wpisu w katalogu dla pliku docelowego.
Więcej informacji na temat procesu archiwizacji można znaleźć w publikacji PostgreSQL 9.0 Memory &Processess.
Kopia zapasowa online:
Aby wykonać kopię zapasową online:
Step 1 : Issue pg_start_backup('lable') in the psql terminal
postgres=# select pg_start_backup('fb');
Step 2 : OS level copy the $PGDATA directory to any Backup Location
$ cp -r $PGDATA /anylocation
Step 3 : Issue pg_stop_backup() in psql terminal.
postgres=# select pg_stop_backup();
Uwaga: Nie jest konieczne, aby te dwie funkcje działały w tym samym połączeniu z bazą danych. Tryb kopii zapasowej jest globalny i trwały.
W PostgreSQL nie ma katalogu do przechowywania czasu rozpoczęcia i zakończenia kopii zapasowej online. Jednak podczas tworzenia kopii zapasowej online kilka plików jest tworzonych i usuwanych.
pg_start_backup('etykieta') i pg_stop_backup to dwie funkcje systemowe do wykonywania kopii zapasowej online. Za pomocą pg_start_backup(„etykieta”) plik backup_label jest tworzony w katalogu $PGDATA, a za pomocą pg_stop_backup() plik „wal-segement-number.backup” tworzony jest w katalogu $PGDATA/pg_xlog. Backup_label poda czas rozpoczęcia i lokalizację Checkpoint segmentu WAL, a także powiadomi instancję PostgreSQL, że Cluster jest w trybie BACKUP-MODE. Plik „wal-segment-number.backup” w katalogu $PGDATA/pg_xlog opisuje czas rozpoczęcia i zakończenia, lokalizację punktu kontrolnego z numerem segmentu WAL.
Uwaga:Po pg_stop_backup() plik backup_label jest usuwany przez instancję PostgreSQL.
Opublikuj swoje komentarze, sugestie.
