Pozwólcie, że spróbuję to zilustrować w skrócie przed wprowadzeniem tych poprawek, wszyscy wiecie, że tryb gotowości jest kluczowym elementem w osiąganiu szybkiego i bezpiecznego odzyskiwania po awarii. W PostgreSQL koncepcja odzyskiwania dotyczy głównie osi czasu w celu zidentyfikowania serii segmentów WAL przed i po PITR lub promocji Standby, aby uniknąć nakładania się segmentów WAL. Identyfikator osi czasu jest powiązany z nazwami plików segmentów WAL (np.:w $PGDATA/pg_xlog/0000000C000000020000009E segment „0000000C” to identyfikator osi czasu). W replikacji strumieniowej zarówno podstawowy, jak i podrzędny będą podążać za tym samym identyfikatorem osi czasu, jednak gdy w trybie gotowości zostanie awansowany jako nowy główny przez przełączenie, podskakuje identyfikator osi czasu, a stary podstawowy odmawia ponownego uruchomienia jako gotowości z powodu różnicy identyfikatorów osi czasu i wyświetla komunikat o błędzie jako:
FATAL: requested timeline 10 is not a child of this server's history
DETAIL: Latest checkpoint is at 2/9A000028 on timeline 9, but in the history of the requested timeline, the server forked off from that timeline at 2/99017E68.
W związku z tym nowy tryb gotowości musi być budowany od zera, jeśli rozmiar bazy danych jest ogromny, odbudowa trwa dłużej i przez ten okres nowo promowana podstawa podstawowa będzie działać bez gotowości. Istnieje również inny problem, taki jak:gdy nastąpi przełączenie, Podstawowy wykonuje czyste zamknięcie, proces Walsender wysyła wszystkie zaległe rekordy WAL do trybu gotowości, ale nie czeka na ich replikację przed zakończeniem. Walreceiver nie stosuje tych zaległych rekordów WAL, ponieważ wykrywa zamknięcie połączenia i wyjścia.
Dzisiaj, dzięki dwóm kluczowym aktualizacjom oprogramowania w PostgreSQL 9.3, oba problemy zostały bardzo dobrze rozwiązane przez autorów, a teraz tryb gotowości Streaming Replication Standby konsekwentnie podąża za zmianą osi czasu. Możemy teraz płynnie i bezboleśnie przełączać obowiązki między trybem podstawowym a gotowością, po prostu ponownie uruchamiając i znacznie skracając czas odbudowy trybu gotowości.
Uwaga:Przełączanie/Przełączanie z powrotem nie jest możliwe, jeśli archiwa WAL nie są dostępne dla obu serwerów i w procesie przełączania Podstawowa baza danych musi wykonać czyste zamknięcie (tryb normalny lub szybki).
Aby wyświetlić demonstrację, zacznijmy od konfiguracji replikacji strumieniowej (wiki do konfiguracji SR), którą skonfigurowałem w mojej lokalnej maszynie wirtualnej między dwoma klastrami (5432 jako podstawowy i 5433 jako tryb gotowości) współdzielących wspólną lokalizację archiwów WAL, ponieważ oba klastry powinny mieć pełny dostęp sekwencji archiwów WAL. Spójrz na udostępnioną poniżej migawkę ze szczegółami konfiguracji i bieżącym identyfikatorem osi czasu, aby lepiej zrozumieć koncepcję.
Na tym etapie każdy musi dobrze zrozumieć, że Switchover i Switchback są działaniami planowanymi. Teraz konfiguracja SR na miejscu, możemy zamienić obowiązki podstawowe i rezerwowe, jak pokazano poniżej:
Kroki przełączania:
Krok 1. Czyste zamknięcie Podstawowego[5432] (-m szybkie lub inteligentne)
[postgres@localhost:/~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data stop -mf
waiting for server to shut down.... done
server stopped
Krok 2. Sprawdź stan synchronizacji i stan gotowości [5433] przed jej promowaniem:
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5433 -c 'select pg_last_xlog_receive_location() "receive_location",
pg_last_xlog_replay_location() "replay_location",
pg_is_in_recovery() "recovery_status";'
receive_location | replay_location | recovery_status
------------------+-----------------+-----------------
2/9F000A20 | 2/9F000A20 | t
(1 row)
Gotowość w pełnej synchronizacji. Na tym etapie możemy bezpiecznie promować go jako Podstawowy.
Krok 3. Otwórz tryb gotowości jako nowy podstawowy przez pg_ctl promuj lub tworząc plik wyzwalacza.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ grep trigger_file data_slave/recovery.conf
trigger_file = '/tmp/primary_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_down.txt
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5433 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
f
(1 row)
In Logs:
2014-12-29 00:16:04 PST-26344-- [host=] LOG: trigger file found: /tmp/primary_down.txt
2014-12-29 00:16:04 PST-26344-- [host=] LOG: redo done at 2/A0000028
2014-12-29 00:16:04 PST-26344-- [host=] LOG: selected new timeline ID: 14
2014-12-29 00:16:04 PST-26344-- [host=] LOG: restored log file "0000000D.history" from archive
2014-12-29 00:16:04 PST-26344-- [host=] LOG: archive recovery complete
2014-12-29 00:16:04 PST-26342-- [host=] LOG: database system is ready to accept connections
2014-12-29 00:16:04 PST-31874-- [host=] LOG: autovacuum launcher started
Tryb gotowości został promowany jako nadrzędny i zastosowano nową oś czasu, którą można zauważyć w dziennikach.
Krok 4. Zrestartuj starą wersję podstawową w trybie gotowości i zezwól na śledzenie nowej osi czasu, przekazując „recovery_target_timline='latest'” w pliku $PGDATA/recovery.conf.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ cat data/recovery.conf
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=localhost port=5433 user=postgres'
restore_command = 'cp /opt/PostgreSQL/9.3/archives93/%f %p'
trigger_file = '/tmp/primary_131_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data start
server starting
Jeśli przejdziesz przez plik recovery.conf, jest bardzo jasne, że stary podstawowy próbuje połączyć się z portem 5433 jako nowy tryb gotowości wskazujący wspólną lokalizację archiwów WAL i zaczął.
In Logs:
2014-12-29 00:21:17 PST-32315-- [host=] LOG: database system was shut down at 2014-12-29 00:12:23 PST
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000E.history" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: entering standby mode
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000D00000002000000A0" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: restored log file "0000000D.history" from archive
2014-12-29 00:21:17 PST-32315-- [host=] LOG: consistent recovery state reached at 2/A0000090
2014-12-29 00:21:17 PST-32315-- [host=] LOG: record with zero length at 2/A0000090
2014-12-29 00:21:17 PST-32310-- [host=] LOG: database system is ready to accept read only connections
2014-12-29 00:21:17 PST-32325-- [host=] LOG: started streaming WAL from primary at 2/A0000000 on timeline 14
Krok 5. Sprawdź nowy stan gotowości.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5432 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
t
(1 row)
Fajnie, bez żadnej ponownej konfiguracji przywróciliśmy stary Główny jako nowy tryb gotowości.
Kroki przełączania wstecz:
Krok 1. Wykonaj czyste zamknięcie nowego głównego [5433]:
[postgres@localhost:/opt/~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_slave stop -mf
waiting for server to shut down.... done
server stopped
Krok 2. Sprawdź stan synchronizacji nowego trybu gotowości [5432] przed promocją.
Krok 3. Otwórz nowy tryb gotowości [5432] jako podstawowy, tworząc plik wyzwalacza lub promujący pg_ctl.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_131_down.txt
Krok 4. Ponowne uruchomienie zatrzymało nowy główny [5433] jako nowy tryb gotowości.
[postgres@localhost:/opt/PostgreSQL/9.3~]$ more data_slave/recovery.conf
recovery_target_timeline = 'latest'
standby_mode = on
primary_conninfo = 'host=localhost port=5432 user=postgres'
restore_command = 'cp /opt/PostgreSQL/9.3/archives93/%f %p'
trigger_file = '/tmp/primary_down.txt'
[postgres@localhost:/opt/PostgreSQL/9.3~]$ /opt/PostgreSQL/9.3/bin/pg_ctl -D /opt/PostgreSQL/9.3/data_slave start
server starting
Możesz zweryfikować dzienniki nowego trybu gotowości.
In logs:
[postgres@localhost:/opt/PostgreSQL/9.3/data_slave/pg_log~]$ more postgresql-2014-12-29_003655.log
2014-12-29 00:36:55 PST-919-- [host=] LOG: database system was shut down at 2014-12-29 00:34:01 PST
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000F.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: entering standby mode
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000F.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000E00000002000000A1" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: restored log file "0000000E.history" from archive
2014-12-29 00:36:55 PST-919-- [host=] LOG: consistent recovery state reached at 2/A1000090
2014-12-29 00:36:55 PST-919-- [host=] LOG: record with zero length at 2/A1000090
2014-12-29 00:36:55 PST-914-- [host=] LOG: database system is ready to accept read only connections
2014-12-29 00:36:55 PST-929-- [host=] LOG: started streaming WAL from primary at 2/A1000000 on timeline 15
2014-12-29 00:36:56 PST-919-- [host=] LOG: redo starts at 2/A1000090
Bardzo fajnie, bez zbytniego czasu zamieniliśmy się obowiązkami serwerów Primary i Standby. Możesz nawet zauważyć przyrost identyfikatorów osi czasu z dzienników dla każdej promocji.
Podobnie jak inne, wszystkie moje posty są częścią dzielenia się wiedzą, wszelkie komentarze lub poprawki są mile widziane.
