Jak PostgreSQL obsługuje punkty kontrolne w trakcie tworzenia kopii zapasowej z obsługą WAL?

Na PostgreSQL v9.0 mam działający system archiwizacji WAL. Więc WAL archiwizuje regularnie (gdy tworzone są 3 WAL lub jeśli WAL jest starszy niż 15 minut).

Teraz dodaję binarną kopię zapasową katalogu PG_DATA (z wyłączeniem podkatalogu pg_xlog). Aby to zrobić, wykonuję pg_start_backup(),kopię binarną i pg_stop_backup().

Myślę, że rozumiem całkiem dobrze, co robią pg_start_backup i pg_stop_backup, pierwszy robi punkt kontrolny, a ostatni zapewnia, że ​​ostatni plik WAL jest zarchiwizowany.

Z oficjalnej dokumentacji wynika, że ​​w przypadku kopii danych binarnych powinniśmy:

Wykonaj kopię zapasową, używając dowolnego wygodnego narzędzia do tworzenia kopii zapasowych systemu plików, takiego jak tar lub cpio (nie pg_dump lub pg_dumpall). Nie jest to konieczne ani pożądane, aby zatrzymać normalne działanie bazy danych podczas wykonywania tej czynności.

Więc jestem dość zakłopotany. Oznacza to, że podczas wykonywania kopii można wykonać punkt kontrolny. Widziałem dużo dokumentacji stwierdzającej, że polecenie kopiowania powinno umożliwiać zmiany danych podczas wykonywania kopii, nie mam nic przeciwko, po prostu kwestia znalezienia odpowiedniego narzędzia. Ale moje pytanie brzmi jaki sposób postgreSQL zajmie się odzyskiwaniem zawartości pg_data zawierającej niektóre pliki, które są niespójne (niektóre przed punktem kontrolnym, inne po)?

Ponownie odtwarzając dzienniki transakcji, Postgresql będzie w stanie ustawić wszystkie te pliki we właściwym stanie? Widziałem, że tworzenie tabel i operacje upuszczania są niebezpieczne podczas wykonywania kopii zapasowej. Czy nie ma niebezpiecznych operacji, takich jak polecenia próżniowe ? Czy pg_backup zawiesza operacje próżniowe? Czy powinienem wykonać kopię pliku global / pg_control na końcu na początku procesu kopiowania binarnego? Czy powinienem używać systemu plików z włączoną migawką (np. Z zamrożeniem xfs), aby uzyskać szybszy proces przywracania?

Widziałem, że awaria skryptu kopii zapasowej nie uruchomi automatycznie pg_stop_backup, więc istnieje szansa, że ​​mój stan kopii zapasowej będzie trwał przez długi czas (dopóki moje nagios nie zadzwoni do kogoś, aby naprawić pg_stop_backup ()). Więc jeśli coś jest inne w PostgreSQL między tymi dwoma poleceniami, chciałbym to wiedzieć, aby zrozumieć, jaki może to mieć wpływ.

Oświeć mnie, proszę.

Zapytałeś:

jak postgreSQL zajmie się odzyskiwaniem z zawartością pg_data zawierającą niektóre niespójne pliki.

pg_start_backup()upewnij się, że plik danych jest co najmniej tak nowy jak punkt kontrolny. Podczas odzyskiwania dzienniki są stosowane.

Jeśli dane są stare, dziennik je zaktualizuje.

Jeśli dane są nowe, dziennik będzie miał tę samą zawartość. Ponowne pisanie tego nie będzie bolało.

Dane nigdy nie są nowsze niż dziennik, ponieważ dzienniki są zapisywane z wyprzedzeniem (WAL).

Zapytałeś:

... xfs-freeze...

xfs-freezejest podobny pg_start_backup(), nie robi migawki. Aby to zrobić, potrzebujesz menedżera woluminów.

Zapytałeś:

... dlaczego tworzenie obszaru tabel i tworzenie instrukcji bazy danych nie jest obsługiwane, jeśli WAL może odtworzyć wszystko?

Jest obsługiwany, tylko trochę gotcha. Zobacz http://www.postgresql.org/docs/8.1/static/backup-online.html :

23.3.5 Ostrzeżenia

Polecenia CREATE TABLESPACE są rejestrowane w WAL za pomocą dosłownej ścieżki bezwzględnej, a zatem będą odtwarzane jako kreacje obszaru tabel o tej samej ścieżce bezwzględnej. Może to być niepożądane, jeśli dziennik jest odtwarzany na innym komputerze. Może to być niebezpieczne, nawet jeśli dziennik jest odtwarzany na tym samym komputerze, ale w nowym katalogu danych: powtórka nadal nadpisuje zawartość oryginalnego obszaru tabel. Aby uniknąć tego rodzaju potencjalnych problemów, najlepszą praktyką jest zrobienie nowej podstawowej kopii zapasowej po utworzeniu lub upuszczeniu obszarów tabel.