Migawki pamięci masowej dla spójnego tworzenia kopii zapasowych postgresql - różne woluminy danych i dzienników

Pracujemy z wieloma maszynami wirtualnymi z systemem Linux w środowisku vmware / Shared Storage, każda z nich ma własną instancję postgreSQL (połączenie wersji 9.0 i 9.3). Obecnie cała maszyna wirtualna znajduje się na jednej partycji / woluminie głównym i odnieśliśmy wielki sukces (~ 8 lat), wykorzystując migawki bazowych woluminów VMFS do tworzenia kopii zapasowych / przywracania (i replikacji na naszej stronie DR).

Ze względu na architekturę naszego magazynu, korzystne byłoby rozdzielenie plików WAL postgres na wolumin niebuforowany, głównie z zapisem, aby dać nam mniej pamięci podręcznej po stronie magazynu. Dzięki naszej pamięci masowej (Nimble Storage) możemy przypisać oba woluminy do pojedynczej grupy ochrony / migawek, ale nie byłem w stanie wyjawić od naszego dostawcy, że migawki będą się odbywały DOKŁADNIE w tym samym czasie na wszystkich woluminach w grupie ochrony - prawdopodobnie tak będzie, ale zawsze istnieje szansa, że ​​jego milisekundy się rozdzielą.

W tym celu przeprowadziliśmy kilka eksperymentów, wszystkie zapisując dane do bazy danych tak szybko, jak to możliwe, używając pg_bench. Po eksperymentach przywróciliśmy nasze woluminy migawkowe i uruchomiliśmy postgres VM +

• Wykonaj migawkę woluminów danych i dziennika blisko jednocześnie - wynik: DB odzyskano
• Najpierw wolumin danych migawki, wolumin dziennika ~ 1 minutę później - wynik: odzyskano DB
• Najpierw wolumin dziennika migawki, wolumin danych ~ 1 minutę później - wynik: odzyskano DB
• Najpierw wolumin dziennika migawki, wolumin danych ~ 3 minuty później, po tym, jak punkt kontrolny WAL zapisał nowe dane w plikach danych: wynik: odzyskano DB

Testy wydają się nam więc mówić, o ile obie migawki są spójne na poziomie głośności i względnie blisko siebie, otrzymujesz spójną kopię bazy danych na podstawie czasu migawki woluminów WAL / Log.

Moje pytanie: czy to jest bezpieczne? Jakie są najważniejsze przypadki, których nam brakuje w naszych testach i co może pójść nie tak?

Dokument Postgresa wskazuje, że nie jest to bezpieczne, ale testy wydają się wskazywać na jego solidność: http://www.postgresql.org/docs/9.1/static/backup-file.html

Jeśli baza danych jest rozproszona na wiele systemów plików, może nie istnieć żaden sposób uzyskania dokładnie równoczesnych zamrożonych migawek wszystkich woluminów. Na przykład jeśli pliki danych i dziennik WAL znajdują się na różnych dyskach lub obszary tabel znajdują się w różnych systemach plików, użycie kopii zapasowej migawki może być niemożliwe, ponieważ migawki muszą być jednoczesne. Przeczytaj dokumentację systemu plików bardzo uważnie, zanim zaufasz technice spójnego tworzenia migawek w takich sytuacjach.

UWAGA: Tak, wiemy o innych opcjach, aby upewnić się, że są one spójne, takich jak przełączanie PostgreSQL w tryb hot backup lub korzystanie z integracji VMware naszej pamięci masowej w celu wyciszenia samych maszyn wirtualnych, ale szukamy rozwiązania tylko do przechowywania pod kątem szybkości, wygody, i zero wpływu na naszych klientów.

Cytowana dokumentacja mówi wszystko, ale nie obwiniłbym cię, jeśli chcesz spróbować zweryfikować roszczenia dostawcy dotyczące migawek wykonanych w tym samym czasie. Być może sposobem na odkrycie czegoś może być dokładniejsze przetestowanie systemu WAL .

np. Oprócz testów opartych na pgbench, spróbuj dodać losowe wywołania, aby pg_switch_xlog()wymusić rotację dziennika, krótsze i dłuższe interwały punktów kontrolnych (skracanie i wydłużanie checkpoint_timeouti checkpoint_timeout), a nawet używanie małych lub dużych plików wal.

Chyba, że ​​czegoś mi brakuje, dla twoich migawek nie zrobionych w tym samym czasie, przypisałbym odzyskane bazy danych być może odrobiną szczęścia. W tym ostatnim przypadku, wyobraź sobie, wziął swój zrzut dziennika, podczas gdy prąd xlog lokalizacja była, powiedzmy 0/A1C0FFEE. Następnie masz 3 minuty szczególnie dużego obciążenia systemu, co powoduje pełny cykl przeglądania plików WAL, a twoja baza danych jest teraz w 0/DEADBEEFmomencie wykonywania migawki danych. Podczas próby przywrócenia pliki WAL zapisywane w czasie migawki danych już dawno minęły, a odzyskiwanie nie powiedzie się.