A) Jakie jest najlepsze rozwiązanie do regularnego tworzenia kopii zapasowych dużej bazy danych PostgreSQL (wersja 8.3 działająca na najnowszym serwerze Ubuntu); proszę nie mów pg_dump z tymi boleśnie powolne sprawozdania wkładekRozwiązanie do przywracania i tworzenia kopii zapasowych PostgreSQL
B), co jest najlepszym rozwiązaniem dla replikacji bazy danych PostgreSQL, który działa w świecie rzeczywistym
A. pg_dump domyślnie nie używa instrukcji wstawiania. Domyślnie użyje polecenia COPY. Przełącznik wiersza poleceń -d lub --inserts spowoduje, że pg_dump wstawi instrukcje wstawiania do eksportu. Jeśli któryś z tych przełączników znajduje się w poleceniu pg_dump, po prostu usuń je, aby pg_dump użył KOPIUJ.
B. W nadchodzącej wersji PostgreSy będą one gotowe do użycia po wyjęciu z pudełka: simple replication. Myślę, że wydanie 8.4 jest już planowane. Warto więc, o ile to możliwe, o to prosić.
Można użyć Online WAL-Backup być może w połączeniu nocny/dzienny/tygodniowy/comiesięczne pg_dumps. Raz na tydzień/miesiąc powinieneś skopiować cały klaster z dala.
Przywracanie działa całkiem dobrze i prawie nie tracisz danych po wcześniejszym skopiowaniu (rsync jest najlepszy, ponieważ jest bardzo wydajny).
Prędkość jest dobra, ponieważ musi tylko zastosować WAL, które są późniejsze niż najnowsze kopie zapasowe/kopie pełnego klastra.
PITR lub zwrot w czasie. Jest to w zasadzie archiwizacja dzienników transakcji i jest to, o ile wiem, najlepszy sposób tworzenia kopii zapasowych.
Ustawiłem go kilka razy na 8.1, ale powinien być taki sam w 8.3.
W postgresql.conf wszystko, co trzeba zrobić, to dodać to:
archive_command = 'test ! -f /path/to/your/backups/archive_logs/%f && cp -i %p /path/to/your/backups/archive_logs/%f </dev/null'
To polecenie kopiuje dzienniki archiwum do określonego katalogu, gdzie bezpiecznie można kopię zapasową z oprogramowaniem kopii zapasowej wybór.
Aby utworzyć pełną kopię zapasową, musisz najpierw poinformować PostgreSQL o wykonaniu kopii zapasowej. Robi się to za pomocą komendy psql: psql "SELECT pg_start_backup('my_backup');" Po tym wystarczy skopiować katalog danych za pomocą rsync, cpio lub innego narzędzia. Jeśli baza danych jest intensywnie używana, pliki zmieniają się podczas kopiowania, dlatego ważne jest, aby narzędzie poradziło sobie z tym poprawnie, a nie za kaucją.
Po zakończeniu kopiowania, po prostu uruchom psql "SELECT pg_stop_backup();", aby PostgreSQL ponownie je zatrzymał. To, co te komendy robią, polega na umieszczeniu znacznika w dziennikach archiwum, w którym rozpoczęto tworzenie kopii zapasowej, więc w procesie przywracania wie, skąd musi zacząć czytać.
Ta technika może być również używana do podgrzewania w trybie gotowości do replikacji, ale nie będzie ona czytelna, po prostu gotowa do przejęcia w razie nagłej potrzeby. Pełna gotowość jest planowana w I think wersji 8.4, więc do tej pory nie sądzę, że jest inna opcja.
Jedną z rzeczy, która jest wspaniała, jeśli korzystasz z PITR, jest możliwość określenia znacznika czasu, kiedy chcesz, aby dzienniki archiwum były dołączane.W ten sposób można również zapisać bazę danych z wypadków (takich jak usunięcie lub zmiana niektórych danych).
pg_dump domyślnie nie używa instrukcji wstawiania. Domyślnie użyje polecenia COPY. Przełącznik wiersza poleceń -d lub --inserts spowoduje, że pg_dump wstawi instrukcje wstawiania do eksportu. Czy masz na myśli COPY jest zbyt wolny? Czy używasz przełącznika -d lub --inserts? –
Nie wiedziałem, że mogę wyłączyć instrukcje wstawiania, KOPIA jest OK..nie złe – tropikalista