Odzyskiwanie w czasie rzeczywistym (PITR) jest funkcją niektórych systemów operacyjnych i aplikacji bazodanowych, która pozwala na przywrócenie danych lub ustawień systemowych z przeszłej daty.
PITR może być używany do przywracania danych z przeszłości, na przykład gdy baza danych została uszkodzona lub przypadkowo usunięta. Jednakże, istnieje kilka wad z PITR.
Co to jest Point-in-Time Recovery?
Point-in-Time Recovery (PITR) jest funkcją, która pozwala administratorowi bazy danych odzyskać lub przywrócić zestaw danych lub określone ustawienie z określonego czasu w przeszłości. Funkcja ta jest bardzo przydatna, gdy baza danych została uszkodzona lub utracona.
Jest ona również używana do zapewnienia dodatkowej ochrony przed przypadkowym usunięciem informacji w zarchiwizowanej bazie danych. Jako taka, jest często używana w połączeniu z innymi typami kopii zapasowych, takimi jak pełna kopia zapasowa bazy danych.
Ta metoda odzyskiwania rozszerza standardowe operacje tworzenia kopii zapasowych i odzyskiwania danych o odtwarzanie czynności związanych z wykonywaniem zleceń, w tym zlecanie transakcji, które były w toku, ale nie zostały jeszcze zakończone. Proces ten może być przydatny, gdy nośnik użyty do wykonania kopii zapasowej jest uszkodzony lub niedostępny.
Jednak odzyskiwanie w czasie nie może być stosowane do baz danych, które zostały usunięte lub skasowane przez użytkowników. W związku z tym powinno być stosowane tylko wtedy, gdy baza danych jest używana do przechowywania wrażliwych danych.
W MySQL, PITR jest osiągany poprzez włączenie logowania na serwerze i użycie binarnych plików log do przywrócenia lub replikacji bazy danych z powrotem do określonego punktu w czasie. Te pliki dziennika zawierają wszystkie zaangażowane działania serwera w przeszłości, więc są niezawodnym źródłem danych do odzyskiwania w czasie.
Program pg_wal jest odpowiedzialny za generowanie plików WAL, które rejestrują wszystkie zaangażowane działania wykonane na bazie danych od momentu jej utworzenia. Oprócz przechowywania tych plików WAL w bazie danych, tworzy on również serię nazw plików segmentów WAL, które identyfikują czas tych zapisów.
Gdy linia czasowa zostanie zakończona, generuje nowe numery ID linii czasowej i dodaje je do serii nazw plików segmentów WAL. Gdy tworzona jest nowa oś czasu, te numery ID są używane do generowania nowych plików segmentów WAL, które nie nadpisują istniejących.
Jest to bardzo pomocna funkcja w PostgreSQL i może być ratunkiem podczas archiwizacji bazy danych. Zapobiega ona powstawaniu wielu nakładających się na siebie archiwów i zapewnia, że każde archiwum jest unikalne. Ponadto zapewnia, że nowe archiwum nie nadpisze zawartości poprzednich zarchiwizowanych osi czasu, a nowa linia czasu będzie zawsze zsynchronizowana z aktualnym czasem.
PITR z wykorzystaniem pozycji zdarzeń
Point-in-Time Recovery (PITR) to funkcja w MySQL, która pozwala na przywrócenie bazy danych z określonego punktu w czasie, wykorzystując pliki dziennika, które zostały zapisane podczas operacji tworzenia kopii zapasowej. Może to pomóc firmie w odzyskaniu danych po wypadku lub katastrofie, która spowodowała uszkodzenie danych i tabel w bazie danych.
Pomaga również zapobiec utracie danych, która może nastąpić w wyniku przypadkowego usunięcia tabeli lub wykonania aktualizacji bazy danych za pomocą poleceń SQL. PITR wykorzystuje plik dziennika do zapisu wszystkich transakcji, które miały miejsce w bazie danych i umożliwia przywrócenie bazy danych z dowolnego punktu w czasie.
PITR pozwala również na wykorzystanie logów wyprzedzających zapis (WAL), które mogą być archiwizowane w katalogu pg_wal. Logi te są używane do przechowywania wszystkich zmian dokonanych w bazie danych od czasu wykonania ostatniej pełnej kopii zapasowej. Logi te są ważne, ponieważ pozwalają na przywrócenie bazy danych z dowolnego punktu od momentu utworzenia kopii zapasowej, a także są przydatne do cofnięcia bazy danych w przypadku, gdy coś poszło nie tak z bazą danych.
Jednym z najczęstszych typów PITR używanych w MySQL jest przywracanie bazy danych z punktu w czasie, który został określony za pomocą pozycji zdarzenia. Ta metoda jest nieco bardziej precyzyjna niż użycie opcji daty i czasu, ponieważ może zapewnić, że konkretna transakcja jest cofana dokładnie do właściwej pozycji w dzienniku binarnym.
Aby użyć tej metody, należy stworzyć okrojony plik dziennika, który zawiera dane z uszkodzonej tabeli oraz wszystkie polecenia SQL, które zostały wykonane w tym czasie. Ten okrojony plik dziennika może być następnie użyty w procesie PITR, aby zapewnić, że polecenia SQL, które były wykonywane w czasie wypadku lub katastrofy, są prawidłowo rolowane.
Użycie opcji pozycji zdarzenia w PITR jest świetnym sposobem na zapewnienie, że baza danych jest rolowana wstecz do dokładnego czasu i daty, zwłaszcza jeśli wiele transakcji było wykonywanych w tym czasie. Może to pomóc firmie zmniejszyć ilość szkód, które mogły zostać spowodowane przez awarię. Może to również pomóc firmie uniknąć konieczności wykonywania wielu pełnych kopii zapasowych bazy danych, które mogą pochłaniać dużo miejsca i czasu.
PITR z wykorzystaniem plików WAL
Pliki WAL (write-ahead logs) są wykorzystywane głównie przez systemy RDBMS jako sposób zapewnienia trwałości i spójności podczas zapisu danych do systemów pamięci masowej. Zawierają one zestaw rekordów dziennika transakcji, które są zapisywane za każdym razem, gdy dokonywana jest zmiana w bazie danych. Logi te są zwykle przechowywane w katalogu pg_wal na serwerze głównym, ale mogą być również archiwizowane przy użyciu opcji konfiguracyjnej archive_command i kopiowane do długoterminowego przechowywania.
Archiwizacja segmentów WAL jest przydatna na wiele sposobów, przede wszystkim do odzyskiwania danych w trybie point-in-time. Najważniejszą zaletą jest to, że jeśli masz serię kopii zapasowych bazy i ciągły ciąg zarchiwizowanych plików segmentów WAL, możesz łatwo odtworzyć zmiany w bazie danych.
Możesz określić „cel odzyskiwania” podczas pierwszego uruchomienia odzyskiwania – punkt w czasie, kiedy spodziewasz się, że zmiany będą potrzebne. Proces odzyskiwania będzie próbował pobrać i odtworzyć wszystkie zarchiwizowane pliki segmentów WAL do tego momentu. Jeśli znajdzie uszkodzone lub brakujące dane WAL, zatrzyma się i nie będzie kontynuowany. Oznacza to, że proces odzyskiwania rozpocznie się niemal dokładnie tam, gdzie się rozpoczął, jeśli uruchomisz go ponownie i określisz cel odzyskiwania przed punktem uszkodzenia.
Bardzo przydatną cechą archiwizacji segmentów WAL jest to, że każdy plik segmentu WAL w archiwum otrzymuje identyfikator osi czasu. Identyfikator ten jest częścią nazwy pliku segmentu WAL i pozwala systemowi wybrać właściwy plik segmentu WAL podczas odtwarzania historii.
Kiedy tworzona jest nowa linia czasu, będzie się ona rozgałęziać od poprzednich linii czasu, a system tworzy plik „timeline history”, który zawiera znacznik czasu dla każdej nowo utworzonej linii czasu. Plik historii osi czasu jest archiwizowany wraz z plikami segmentów WAL i jest używany przez PostgreSQL do wyboru odpowiednich plików segmentów podczas odtwarzania historii zawierającej wiele linii czasu.
Ważne jest, aby śledzić, które linie czasowe zostały zarchiwizowane, aby w razie potrzeby można było przywrócić z najnowszej. Można to zrobić modyfikując plik historii i dodając komentarz dla każdej osi czasu, która została zarchiwizowana.
PITR przy użyciu osi czasu
PITR jest dostępny w PostgreSQL od wersji 8 i pozwala użytkownikom na przywrócenie działającego klastra bazy danych do dowolnego punktu w czasie przy użyciu bazowej kopii zapasowej oraz logów archiwalnych utworzonych przez funkcję ciągłej archiwizacji. Jest to przydatne w wielu przypadkach użycia, takich jak odzyskiwanie po błędach DML lub DDL.
Chociaż podstawowa kopia zapasowa nie jest w rzeczywistości migawką całej bazy danych, zapewnia dokładny obraz tego, jak dane wyglądały w danym momencie. Jeśli jednak odzyskiwanie danych pójdzie źle, przywrócone dane mogą być uszkodzone i niemożliwe do odzyskania.
Jednym ze sposobów rozwiązania tego problemu są linie czasowe w PostgreSQL. Za pomocą osi czasu możesz odzyskać dane do dowolnego wcześniejszego stanu, włączając w to stany w gałęziach osi czasu, które wcześniej opuściłeś. Pozwala to uniknąć konieczności przywracania do starego i niemożliwego do opanowania zestawu punktów w czasie metodą prób i błędów.
Oś czasu jest bardzo centralną koncepcją PITR i jest używana do rozróżnienia pomiędzy oryginalnym klastrem bazy danych a odzyskanymi. Każdy klaster bazy danych otrzymuje timelineId, który jest 4-bajtową niepodpisaną liczbą całkowitą zaczynającą się od 1.
Jest to kluczowy element PITR, ponieważ jest to jedyny sposób na zapewnienie, że zrekonstruowany klaster bazy danych odpowiada oryginalnemu. W przypadku, gdy linie czasowe są niespójne, PITR może nadal odzyskać poprawny stan poprzez określenie, który segment WAL należy do której linii czasowej.
Kiedykolwiek oś czasu jest przywracana, odpowiadający jej segment WAL jest odtwarzany i rejestrowany. Dodatkowo, uaktualniany jest również plik historii osi czasu, dzięki czemu wszelkie zmiany dokonane w osi czasu są zachowane.
Jeśli posiadasz dużą liczbę osi czasu, warto skopiować je do osobnych folderów, aby można je było łatwo odzyskać podczas przywracania. Pomoże to również zapobiec przywracaniu rekursywnemu, ułatwiając określenie, do których z osi czasu należy odzyskać dane i zlokalizowanie najważniejszych z nich.
Ponadto, można użyć polecenia wal-verify, aby sprawdzić, czy bieżąca oś czasu jest równa najwyższemu id osi czasu, który jest w magazynie. Jest to pomocne w zapobieganiu przywróceniu niewłaściwej osi czasu, a także może pomóc w rozwiązaniu innych problemów, które mogą wystąpić podczas przywracania.
Podobne tematy