PITR całego serwera: restore to dopiero początek

Kiedy to ma sens

PITR całego serwera wybieramy wtedy, gdy problem dotyczy wspólnego stanu.

Przykłady:

błędny job masowo zmienił rekordy
migracja uszkodziła dane
operator skasował ważne tabele
aplikacja przez godzinę zapisywała błędne wartości
atakujący zmienił dane i trzeba wrócić przed zmianę

Jeżeli problem jest tylko w kodzie, rollback wydania może wystarczyć.

Jeżeli problem dotyczy jednej tabeli albo jednej bazy, pełny PITR serwera może być zbyt dużym młotkiem.

Ale jeśli cały stan produkcji jest podejrzany, trzeba przestać łatać rekordy na żywo.

Wtedy pytanie brzmi:

do którego momentu wracamy?

Najpierw zatrzymać pogłębianie szkody

Zanim zaczniemy odtwarzać, trzeba ograniczyć zapisy.

To może oznaczać:

włączenie maintenance mode
zablokowanie ścieżek zapisu
zatrzymanie workerów
zatrzymanie cronów
odcięcie integracji
zrobienie snapshotu aktualnego stanu

Snapshot popsutego stanu brzmi dziwnie, ale bywa potrzebny.

Może zawierać dane, których nie chcemy stracić.

Może być dowodem do analizy.

Może pozwolić później przenieść wybrane rekordy do odtworzonego środowiska.

Najgorszy wariant to odtwarzać bazę, kiedy stara produkcja dalej przyjmuje zapisy i nikt nie wie, które z nich później będą potrzebne.

Odtworzyć obok, nie na ślepo

Bezpieczny model jest prosty:

stara produkcja zostaje zamrożona
nowy serwer odtwarzamy obok
walidujemy nowy stan
dopiero potem przełączamy ruch

Odtwarzanie w miejscu może być kuszące, bo wydaje się prostsze.

Ale odbiera możliwość porównania.

Jeżeli restore pójdzie źle, nie mamy ani starego stanu, ani nowego.

Odtworzenie obok daje czas na sprawdzenie:

czy baza wstała
czy aplikacja umie się połączyć
czy krytyczne tabele mają oczekiwaną liczbę rekordów
czy błąd, przed którym uciekamy, zniknął
czy nie wróciliśmy za daleko

W PostgreSQL szczegóły zależą od sposobu backupu, ale model mentalny jest ten sam:

backup bazowy
archiwum WAL
target time
promote odtworzonej instancji
walidacja

Przepięcie ruchu

Po walidacji trzeba przełączyć aplikację na odtworzoną bazę.

To może być zmiana:

DNS
connection string
sekretu w platformie
endpointu managed database
Service albo konfiguracji routingu

Ważne, żeby wiedzieć, gdzie naprawdę jest źródło prawdy.

Jeżeli część workerów nadal pisze do starej bazy, system rozszczepi się na dwa światy.

Dlatego przed przepięciem trzeba mieć listę klientów bazy:

API
workery
cron jobs
narzędzia admina
integracje
read modele
procesy migracyjne

Po przepięciu trzeba sprawdzić nie tylko aplikację webową.

Trzeba sprawdzić też procesy w tle.

To one często zapisują dane długo po tym, jak główny ruch wygląda już dobrze.

Co z danymi po punkcie odtworzenia

PITR oznacza, że świadomie wracamy do przeszłości.

Jeżeli odtwarzamy bazę do 10:42, wszystko po 10:42 znika z odtworzonego świata.

To może być akceptowalne.

Może też wymagać dogrania części danych.

Przykłady:

zamówienia złożone po punkcie odtworzenia
płatności potwierdzone przez operatora
zgłoszenia wysłane przez klientów
eventy opublikowane do innych systemów

Tu nie ma uniwersalnego automatu.

Trzeba zdecydować, które dane są prawdą biznesową, a które można odtworzyć z zewnętrznych systemów.

Czasem najlepsza decyzja brzmi:

wracamy do 10:42 i ręcznie reconciliujemy płatności z ostatniej godziny

To nadal może być lepsze niż utrzymywanie uszkodzonego stanu.

Minimalny runbook

Runbook PITR całego serwera powinien zawierać:

kto podejmuje decyzję o PITR
jak wybieramy target time
jak zamrażamy zapisy
jak robimy snapshot aktualnego stanu
gdzie odtwarzamy nową instancję
jak walidujemy dane
jak przełączamy wszystkie klienty
jak sprawdzamy, że stara instancja nie przyjmuje zapisów
jak dokumentujemy utracone dane

Najważniejsze zdanie:

restore bazy to nie koniec recovery

To dopiero moment, w którym mamy kandydatkę na nową produkcję.

Produkcją staje się dopiero po walidacji i przepięciu całego ruchu.