Myślałem o tym, co napisałeś i oto kilka pomysłów dla Ciebie:
- Jeśli potrzebujesz kopii zapasowej, która będzie naprawdę spójna do pewnego momentu, musisz użyć pg_basebackup lub pg_barman (wewnętrznie używa pg_basebackup) - wyjaśnienie znajduje się w 1. łączu poniżej. Najnowsze pg_basebackup 10 przesyła strumieniowo logi WAL, dzięki czemu tworzysz kopię zapasową również wszystkich zmian dokonanych podczas tworzenia kopii zapasowej. Oczywiście ta kopia zapasowa zajmuje tylko całą instancję PG. Z drugiej strony nie blokuje żadnego stołu. A jeśli robisz to ze zdalnej instancji, to powoduje to tylko niewielkie obciążenie procesora na instancji PG, a IO dysku nie jest tak duże, jak sugerują niektóre teksty. Zobacz linki 4 o moich doświadczeniach. Przywrócenie jest dość proste - patrz link 5.
- Jeśli używasz pg_dump, musisz zrozumieć, że nie masz gwarancji, że twoja kopia zapasowa jest naprawdę spójna w danym momencie - ponownie zobacz link 1. Istnieje możliwość użycia migawki bazy danych (zobacz linki 2 i 3), ale nawet z nim nie można liczyć na 100% spójności. Używaliśmy pg_dump tylko na naszej analitycznej bazie danych, która ładuje nowe tylko 1x dziennie (wczorajsze partycje z produkcyjnej bazy danych). Możesz to przyspieszyć za pomocą opcji równoległej (działa tylko dla formatu kopii zapasowej katalogu). Ale minusem jest znacznie większe obciążenie instancji PG - większe zużycie procesora, znacznie wyższe IO dysków. Nawet jeśli uruchomisz pg_dump zdalnie - w takim przypadku zapisujesz tylko dyskowe IO do zapisywania plików kopii zapasowej. Dodatkowo pg_dump musi umieścić blokadę odczytu na tabelach, aby mogła kolidować z nowymi wstawkami lub z replikacją (gdy wzięta na replikę). Ale gdy Twoja baza danych osiągnie setki GB, nawet zrzut równoległy może zająć godziny, a w tym momencie i tak będziesz musiał przejść na pg_basebackup.
- pg_barman to „wygodna wersja” pg_basebackup + pozwala zapobiegać utracie danych, nawet gdy instancja PG bardzo się zawiesi. Ustawienie go do pracy wymaga więcej zmian, ale zdecydowanie warto. Będziesz musiał ustawić archiwizację logów WAL (patrz link 6) a jeśli masz PG <10 będziesz musiał ustawić "max_wal_senders" i "max_replication_slots" (które i tak są potrzebne do replikacji) - wszystko jest w podręczniku pg-barman chociaż opis nie jest do końca świetna. pg_barman będzie przesyłać strumieniowo i przechowywać rekordy WAL nawet między kopiami zapasowymi, dzięki czemu możesz mieć pewność, że utrata danych w przypadku bardzo poważnej awarii będzie prawie żadna. Ale sprawienie, by to działało, może zająć wiele godzin, ponieważ opisy nie są do końca dobre. pg-barman wykonuje zarówno kopie zapasowe, jak i przywracanie za pomocą swoich poleceń.
Twoja baza danych ma rozmiar 5 GB, więc każda metoda tworzenia kopii zapasowej będzie szybka. Ale musisz zdecydować, czy potrzebujesz odzyskiwania do punktu w czasie i prawie zerowej utraty danych, czy nie - więc jeśli zainwestujesz czas w ustawienie pg-barmana, czy nie.
Linki:
- PostgreSQL, kopie zapasowe i wszystko musisz wiedzieć
- Recenzja papieru:14-możliwa do serializacji Izolacja migawek w PostgreSQL - o zrzutach
- Równoległe zrzucanie baz danych - przykład jak używać migawki
- doświadczenia pg_basebackup
- pg_basebackup - przywróć kopię zapasową tar
- Archiwizowanie logów WAL za pomocą skryptu
