EC2 - Jak poprawnie wykonać kopię zapasową danych PostgreSQL?

Oto konfiguracja: 1 mała instancja EC2 Amazon Linux (wspierana przez EBS) z 3 dodatkowymi woluminami. Jest to zarówno serwer WWW, jak i serwer bazy danych. Jeden wolumin na kod, jeden na katalog danych PostgreSQL (8.4) i jeden wolumin do przechowywania plików WAL z PostgreSQL.

(1) Wolumin z plikami WAL będzie również miał podstawową kopię zapasową katalogu danych, który jest kopiowany po wykonaniu pg_start_backup (). Następnie zapisze ciągłe wyjście archiwum z PostgreSQL (pliki WAL). Aby wykonać migawkę tego woluminu, czy jest sens wydawania synchronizacji i zamrażania systemu plików (używając xfs_freeze, jeśli jest to XFS lub dmsetup, jeśli jest to EXT4)? Czy mogę po prostu zrobić migawkę na żywo? Pliki WAL będą wysyłane z szybkością 1 na minutę. Czy jest możliwe, że migawka może zostać zainicjowana podczas kopiowania pojedynczego pliku WAL i powodując uszkodzenie danych?

(2) Kopia zapasowa woluminu zawierającego aktualny katalog danych PostgreSQL również zostanie utworzona (codziennie). Przed zrobieniem migawki tego woluminu wystawiam zrzut pg_dump, a wynikowy plik SQL jest przechowywany w katalogu danych. Czy warto podejmować środki ostrożności w celu zapewnienia spójności rzeczywistych danych w bazie danych? Czy słusznie byłoby założyć, że wykonanie migawki na żywo pozwoli poprawnie (a) wykonać kopię zapasową plików konfiguracyjnych (postgresql.conf, pg_hba.conf, pg_ident.conf) i (b) wykonać kopię zapasową pliku zrzutu SQL. Tworzenie kopii zapasowej tych dwóch rzeczy, pliku zrzutu sql i plików konfiguracyjnych, byłby głównym punktem migawki tego woluminu. Baza danych nie jest bardzo duża, więc nie przeszkadza mi fakt, że pliki danych nadmuchają tę migawkę. W takim przypadku mogę po prostu zrobić migawkę na żywo - prawda?

(2a) Czy lepiej byłoby zachować katalog danych w woluminie głównym i mieć skrypt kopii zapasowej, który kopiuje plik zrzutu sql, a także pliki konfiguracyjne na inny wolumin i wykonuje migawkę tego woluminu po zakończeniu kopiowania?

(3) Co się tyczy woluminu z kodem, czy jest jakiś sens synchronizacji i zamrażania systemu plików? A może można zrobić tylko migawkę na żywo? Dane te powinny być dość „statyczne”.

(4) Czy to solidny schemat tworzenia kopii zapasowych? Kopia zapasowa katalogu głównego nie jest regularnie tworzona, ponieważ po prostu zachowam obraz maszyny po jego skonfigurowaniu i skonfigurowaniu.

Dzięki

Zobacz dokładny podręcznik . Jeśli moja rada w jakikolwiek sposób koliduje z nią, ma rację.

1. Synchronizacja nie jest złym pomysłem, chyba że narzędzie kopiujące fsync () zapisuje każdy plik WAL, który zapisuje i katalog, w którym się znajduje, przed skopiowaniem następnego. Niekompletny ostatni plik WAL nie ma większego znaczenia; w najgorszym razie po prostu go usuwasz. Pg generalnie zadławić niekompletnego WAL - choć nie ma sum kontrolnych zrobić, więc możebądźcie naprawdę pechowi i postarajcie się zastosować śmieciowe dane, które przypadkiem zupełnie przypadkowo wyglądają jak prawdziwe rekordy WAL. W twoim położeniu zsynchronizuję wolumin przed migawką, aby upewnić się, że niepisane brudne bufory w pamięci RAM uderzą w obraz systemu plików na dysku. Zamrożenie pomogłoby uniknąć niechlujnych, ale nie śmiertelnych, częściowo napisanych WAL, więc nie jest to okropny pomysł, ale nie jest niezbędny. Ważne jest, aby mieć nieuszkodzoną oś czasu do momentu powrotu do zdrowia. Osobiście piszę moje WALs do tymczasowej nazwy pliku i zmieniam ich nazwy na ostateczne, tylko raz w pełni skopiowane; jeśli to zrobisz, nie musisz zamrażać.

2. Brzmi poprawnie. Migawka na żywo przypomina test wyciągania wtyczki w systemie na żywo z buforowaniem przez zapis. Baza danych powinna zostać poprawnie przywrócona po przywróceniu z migawki na żywo, tak samo jak po podłączeniu wtyczki. Zalecam zautomatyzowanie testów przywracania z migawek. (Uwaga: Test przywracania migawek nie jest kompletnym substytutem dla testowania wtyczki, ponieważ nie uwzględnia możliwego buforowania dysku, kontrolera RAID itp.). Nie tylko pliki konfiguracyjne i zrzut, ale sama baza danych powinna być w porządku po wykonaniu migawki. Rozważ zsynchronizowanie woluminu przed migawką, aby upewnić się, że wszystkie dane zrzutu itp. Rzeczywiście trafiły na dysk.
   
   2a. Może zaoszczędzić trochę miejsca na dysku. W przeciwnym razie niewielka różnica. Będziesz mógł przechowywać migawki o wiele dłużej bez utraty bazy danych na żywo.

3. Dlaczego nawet migawki woluminu kodu? Zwykła kopia na poziomie pliku może być w porządku. Z pewnością powinna być migawka na żywo.

4. To nie jest solidny schemat tworzenia kopii zapasowych. Nie udaje się to w jednym krytycznym obszarze: nie przeprowadza się testów przywracania ani sprawdzania poprawności. Zawsze powinieneś regularnie testować swoje kopie zapasowe, aby upewnić się, że naprawdę możesz je przywrócić.

   Osobiście zalecam korzystanie z wysyłki WAL lub wysyłanie zrzutów bazy danych do innego hosta , najlepiej nie na Amazon EC2 lub przynajmniej w innym regionie. Ten host powinien wykonać automatyczne testy przywracania, wysyłać raporty o wynikach, a także powinien być sprawdzany ręcznie.

   Chociaż twoje migawki (zawierające zrzuty) będą na S3 i będą tam bezpieczne, nie oznacza to, że będą dostępne, gdy będziesz ich pilnie potrzebować. Oświadczenia firmy Amazon dotyczące trwałości są uspokajające, ale Twoje dane mogą być nadal bezpieczne i całkowicie niedostępne w przypadku awarii usługi S3 w określonym czasie.