Używanie dwufazowych zatwierdzeń na postgres

Myślę, że źle zrozumiałeś PREPARE TRANSACTION .

To oświadczenie kończy pracę nad transakcją, to znaczy powinno zostać wydane po cała praca jest wykonana. Chodzi o to, aby PREPARE TRANSACTION robi wszystko, co potencjalnie mogłoby się nie powieść podczas zatwierdzenia, z wyjątkiem samego zatwierdzenia. Ma to zagwarantować, że kolejne COMMIT PREPARED nie może zawieść.

Chodzi o to, że przetwarzanie wygląda następująco:

• Uruchom START TRANSACTION na wszystkich bazach danych biorących udział w transakcji rozproszonej.

• Wykonaj całą pracę. Jeśli występują błędy, ROLLBACK wszystkie transakcje.

• Uruchom PREPARE TRANSACTION we wszystkich bazach danych. Jeśli to się nie powiedzie, uruchom ROLLBACK PREPARED na tych bazach danych, w których transakcja została już przygotowana i ROLLBACK na innych.

• Raz PREPARE TRANSACTION powiodło się wszędzie, uruchom COMMIT PREPARED we wszystkich zaangażowanych bazach danych.

W ten sposób możesz zagwarantować „wszystko albo nic” w kilku bazach danych.

Jednym z ważnych elementów, o których nie wspomniałem, jest rozproszony menedżer transakcji . Jest to oprogramowanie, które trwale zapamiętuje, gdzie w powyższym algorytmie aktualnie odbywa się przetwarzanie, dzięki czemu może wyczyścić lub kontynuować zatwierdzanie po awarii.

Bez rozproszonego menedżera transakcji zatwierdzanie dwufazowe nie jest wiele warte i jest w rzeczywistości niebezpieczne:jeśli transakcje utkną w fazie „przygotowania”, ale nie zostały jeszcze zatwierdzone, będą nadal utrzymywać blokady i (w przypadku PostgreSQL) blokuje pracę automatycznego odkurzania nawet po ponownym uruchomieniu serwera , ponieważ takie transakcje muszą być trwałe.

Trudno to zrobić dobrze.