PostgreSQL - Failover, failback, switchover w replikacji fizycznej

[host 2: serwer replika]

Failover, czyli awaryjne przerzucenie odpowiedzialności za wszystkie zadania wykonywane przez klaster primary na inną replikowaną instancję, oraz otwarcie jej do zapisu w postgresie w środowiskach produkcyjnych o najwyższych wymogach dostępności. Odpowiada za to zazwyczaj jakieś zewnętrzne narzędzie jak Patroni - czy REPMGR albo autorskie, niestandardowe skrypty czy automatyzacje.

Przejęcie roli primary w postgresie możemy wykonać na kilka sposobów. Za pomocą narzędzia pg_ctl, funkcji pg_promote() lub pliku triggera zdefiniowanego w parametrze postgresql.conf "promote_trigger_file"

/usr/lib/postgresql/15/bin/pg_ctl -D /data_pg/ promote

lub

psql -c "select pg_promote()"

lub

touch /sciezka/do/pliku/triggera

Po wykonaniu jednego polecenia z powyższych replika zakończy odtwarzanie, podniesie znacznik linii czasu o 1 oraz otworzy bazę do zapisu.

Linie czasu (timeline) to mechanika wprowadzona w postgresie, która gwarantuje, że po każdym zakończeniu odtwarzania zmian, czy to po odzyskaniu bazy z kopii zapasowej, czy awansowanie - repliki na instancję, primary spowoduje zmianę "generacji" klastra, - przez co pliki WAL będą generowane z nowym przedrostkiem. Pierwsza wartość w nazwie pliku WAL to numer linii czasu, dzięki czemu, jeżeli przez problemy sieciowe stara instancja primary była - odizolowana od reszty klastra i aplikacji - przed rozwiązaniem problemu wygenerowała nowe pliki WAL, nie będzie konfliktu z logami WAL wygenerowanymi przez świeżo awansowaną na primary replikę. Stara instancja primary będzie nadal generowała logi transakcyjne w poprzedniej linii czasu, a nowa już w podniesionej. Każde podniesienie linii czasu powoduje również stworzenie pliku historii dla danej linii czasu, który zawiera między innymi informację, w którym miejscu linie czasu się rozdzieliły. Dzięki temu unikniemy problemu zduplikowanych logów transakcyjnych i będziemy mogli jednocześnie archiwizować pliki WAL dla obu klastrów, starego primary i nowego. A korzystając z pełnej kopii zapasowej wykonanej dla starej instancji primary oraz plików WAL, będziemy mogli odtworzyć dowolny z klastrów primary do dowolnego momentu w czasie. Dzięki parametrowi postgresa "recovery_target_timeline", którym możemy wskazać, w której linii czasu powinien wykonać odzyskiwanie, domyślną wartością jest - "latest", czyli podczas odtwarzania zmian postgres podąża za wszystkimi zmianami linii czasu, jeżeli posiada odpowiednią liczbę plików WAL w archiwum lub katalogu pg_wal.

[host 1: dawny serwer master]

Failback, czyli powrót do oryginalnej konfiguracji, przed wystąpieniem sytuacji awaryjnej.
Musimy zacząć od podłączenia starej instancji primary do klastra jako replika i zacząć odtwarzać wszystkie zmiany wykonane, kiedy była niedostępna. Czasami jeżeli awansowanie repliki na primary było kontrolowane, wystarczy stworzyć plik standby.signal w PGDATA, zadbać o odpowiednią konfigurację w parametrach primary_conninfo, restore_command i recovery_target_timeline = 'latest' oraz wystartować starą instancję główną jako replikę.
Ale jeżeli doszło do nieplanowanego zatrzymania primary, doszło do awarii sieci lub jakiejkolwiek sytuacji, której pierwotna primary mogła zapisać jakieś dane - nieprzesłane na nowo awansowaną instancję główną, może być wymagane użycie pg_rewind, czyli narzędzia do synchronizacji dwóch katalogów PGDATA odmiennej generacji. Aby móc go użyć, musimy posiadać użytkownika z odpowiednimi uprawnieniami oraz dodać na nowym serwerze primary wpisy pg_hba.conf umożliwiające połączenie do bazy "postgres" i pozwalające na inicjalizację replikacji.

Przykładowe polecenie dla pg_rewind w trybie "dry run". Nie wykonujmy na razie poniższego pg_rewinda, praktyczna demonstracja funkcjonalności przedstawiona będzie trochę później.

/usr/lib/postgresql/15/bin/pg_rewind -n -c -R -D /data_pg/ --source-server='host=<X.X.X.X adres nowego primary> port=5432 user=replicator password=tajnehaslo application_name=pg1 dbname=postgres'

Powyższe polecenie z powodu użycia przełącznika "-n" wykona tzw. "dry run", sprawdzi, czy wszystko jest ustawione jak należy, czy użytkownik ma odpowiednie uprawnienia, czy wszystkie pliki WAL są dostępne. Jeżeli polecenie się powiedzie, możemy usunąć "-n" i wykonać je jeszcze raz.

Przykład polecenia pg_rewind:

/usr/lib/postgresql/15/bin/pg_rewind -c -R -D /data_pg/ --source-server='host=<X.X.X.X adres nowego primary> port=5432 user=replicator password=tajnehaslo application_name=pg1 dbname=postgres'

Po wykonaniu pg_rewind zweryfikujmy, - czy został stworzony plik standby.signal.
Później możemy zmodyfikować primary_conninfo, aby dodać parametr application_name, ustawić odpowiednio wartość dla "primary_slot_name" oraz na aktualnej primary stworzyć nowy fizyczny slot replikacyjny.

Przykład tworzenia fizycznego slotu replikacyjnego:

postgres=# select pg_create_physical_replication_slot('replika_pg1');

Możemy wystartować starą instancję główną, która teraz powinna łączyć się jako replika do nowego primary.
Znając wszystkie kroki, - możemy wykonać failback poprzez switchover, czyli kontrolowaną zamianę ról pomiędzy serwerami. Zatrzymać aktualny primary, awansować replikę i otworzyć do zapisu, upewnić się, że slot replikacyjny istnieje, na zatrzymanej instancji stworzyć "standby.signal" oraz wystartować klaster.

Wykonanie kontrolowanego failovera, krok po kroku.

[host 1: oryginalny serwer master]

Stworzenie użytkownika na aktualnym serwerze obsługującym zapis (master / primary):

postgres@ubuntu:~$ psql

create user replicator with replication password 'tajnehaslo';

GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO replicator;

GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO replicator;

GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO replicator;

GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO replicator;

Zatrzymanie postgresa na klastrze primary "pg1".

postgres@ubuntu-pg1:~$ /usr/lib/postgresql/15/bin/pg_ctl -D /data_pg/ stop

[host 2: oryginalny serwer slave]

Promote instancji standby "pg2" oraz stworzenie slotu replikacyjnego dla starego primary. Nazwę slota replikacyjnego powinniśmy wybrać w sposób pozwalający nam na łatwą identyfikację, - dla jakiej usługi dany slot został stworzony.

postgres=# select pg_promote();

postgres=# select pg_create_physical_replication_slot('pg1');

Sprawdzić wpisy w pg_hba.conf na pg2 czy użytkownik replicator ma możliwość podłączenia się do bazy postgres i jako replikacja. Dodajemy je, jeżeli nie istnieją, podając wewnętrzny adres IP serwera pg1 , czyli naszego dawnego mastera:

host     replication        replicator        192.168.0.26/32        scram-sha-256

host     postgres             replicator        192.168.0.26/32           scram-sha-256

Po edycji pg_hba.conf pamiętajmy o przeładowaniu konfiguracji na pg2.

psql -c "select pg_reload_conf()"

[host 1: oryginalny serwer master]

Synchronizacja katalogu z danymi ze starej instancji primary (pg1) z nową (pg2) za pomocą pg_rewind. Poniższe wykonujemy jako użytkownik systemowy postgres na dawnym serwerze primary - czyli pg1:

/usr/lib/postgresql/15/bin/pg_rewind -c -R -D /data_pg/ --source-server='host=<X.X.X.X adres nowego primary> port=5432 user=replicator password=tajnehaslo application_name=pg1 dbname=postgres'

Sprawdzenie w postgresql.auto.conf, czy konfiguracja recovery (restore_command) dla replikacji wal-shipping i ustawnienia do replikacji strumieniowej (primary_conninfo, primary_slot_name oraz restore_command) są poprawne na pg1. Jeżeli któryś z nich nie istnieje, należy go dodać.
Parametr primary_conninfo powinien odnosić się w connection stringu do odpowiedniego hosta (host=x.x.x.x) oraz zawierać application_name z nazwą dla instancji, która pozwoli nam na jej szybką identyfikację, np. "pg1", a w primary_slot_name (który dopisujemy, - jeśli go nie ma) powinniśmy mieć nazwę slota, który wcześniej stworzyliśmy na pg2, czyli "pg1".
Przykładowo:

restore_command = 'pgbackrest --stanza=test --pg1-path=/data_pg --archive-get %f "%p"'

primary_conninfo = 'host=10.1.0.11 application_name=pg1 ...'

primary_slot_name = 'pg1'

postgres@ubuntu-pg1:~$ /usr/lib/postgresql/15/bin/pg_ctl -D /data_pg/ start

Ostatnim krokiem będzie weryfikacja, czy replikacja działa poprawnie, za pomocą odpowiednich zapytań, z widoku pg_stat_replication na primary (pg2) lub pg_stat_wal_receiver na replica (pg1).

select * from pg_stat_replication;

select * from pg_stat_wal_receiver;