sql >> Databáze >  >> RDS >> PostgreSQL

Implementace Switchover/Switchback v PostgreSQL 9.3.

Tento příspěvek vzdělává sofistikované DBA o tom, jak nastavit elegantní prostředí Switchover a Switchback ve vysoké dostupnosti PostgreSQL. Za prvé, díky autorům oprav Heikki a Fujii za usnadnění přepínání/přepínání v PostgreSQL 9.3. (Omlouvám se, pokud jsem přehlédl další jména).

Pokusím se to krátce ilustrovat před těmito záplatami, všichni víte, že pohotovostní režimy jsou kritickými součástmi pro dosažení rychlé a bezpečné obnovy po havárii. V PostgreSQL se koncept obnovy zabývá především časovými osami k identifikaci řady segmentů WAL před a po PITR nebo podpoře pohotovostního režimu, aby se zabránilo překrývání segmentů WAL. ID časové osy jsou spojeny s názvy souborů segmentů WAL (např.:- V $PGDATA/pg_xlog/0000000C000000020000009E segmentu „0000000C“ je ID časové osy). Ve streamovací replikaci budou primární i podřízená zařízení sledovat stejné ID časové osy, ale když Standby povýší jako nový hlavní server přepnutím, narazí na ID časové osy a starý primární odmítne restartovat jako pohotovostní režim kvůli rozdílu v ID časové osy a zobrazí chybovou zprávu 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.

Nový Standby tedy musí být postaven od nuly, pokud je velikost databáze obrovská, pak bude delší doba na přestavbu a po tuto dobu poběží nově propagovaný Primární bez Standby. Existuje také další problém, například když dojde k přepnutí Primární provede čisté vypnutí, proces Walsender odešle všechny zbývající záznamy WAL do pohotovostního režimu, ale před ukončením nečeká na jejich replikaci. Walreceiver nedokáže použít tyto zbývající záznamy WAL, když detekuje uzavření spojení a ukončí se.

Dnes, se dvěma klíčovými aktualizacemi softwaru v PostgreSQL 9.3, oba problémy autoři velmi dobře řešili a nyní Streaming Replication Standby důsledně sledují přepínání časové osy. Nyní můžeme hladce a bezbolestně přepínat povinnosti mezi Primárním a Pohotovostním režimem pouhým restartováním a výrazným zkrácením doby přestavby Pohotovostního režimu.

Poznámka:Přepnutí/přepnutí není možné, pokud archivy WAL nejsou přístupné pro oba servery a v procesu přepnutí Primární databáze se musí čistě vypnout (normální nebo rychlý režim).

Pro ukázku začněme nastavením streamovací replikace (wiki k nastavení SR), kterou jsem nakonfiguroval na svém místním virtuálním počítači mezi dvěma clustery (5432 jako primární a 5433 jako pohotovostní) sdílejícími společné umístění archivů WAL, protože oba clustery by měly mít úplný přístup sekvence archivů WAL. Podívejte se na snímek sdílený níže s podrobnostmi o nastavení a aktuálním ID časové osy pro lepší pochopení konceptu.

V této fázi musí každý dobře chápat, že přechod a přechod jsou plánované činnosti. Nyní je nastavení SR na místě a můžeme si vyměnit povinnosti primárního a pohotovostního režimu, jak je znázorněno níže:

Kroky přepnutí:

Krok 1 Proveďte čisté vypnutí Primárního[5432] (-m rychlé nebo chytré)

[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. Než jej povýšíte, zkontrolujte stav synchronizace a obnovení pohotovostního režimu[5433]:

[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)

Pohotovostní režim v úplné synchronizaci. V této fázi jej můžeme bezpečně propagovat jako primární.
Krok 3. Otevřete Pohotovostní režim jako nový Primární pomocí pg_ctl propagace nebo vytvoření spouštěcího souboru.

[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

Pohotovostní režim byl povýšen jako hlavní a následovala nová časová osa, které si můžete všimnout v protokolech.
Krok 4. Restartujte staré Primární jako pohotovostní režim a umožněte sledovat novou časovou osu předáním „recovery_target_timline=’latest'“ v souboru $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

Pokud projdete recovery.conf, je zcela jasné, že se starý Primární pokoušel připojit k portu 5433 jako nový pohotovostní režim s odkazem na společné umístění archivů WAL a začal.

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 Ověřte nový pohotovostní stav.

[postgres@localhost:/opt/PostgreSQL/9.3~]$ psql -p 5432 -c "select pg_is_in_recovery();"
pg_is_in_recovery
-------------------
t
(1 row)

Skvělé, bez jakéhokoli přenastavení jsme vrátili staré Primární jako nový pohotovostní režim.

Kroky přepnutí:

Krok 1 Proveďte čisté vypnutí nového primárního [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 Před povýšením zkontrolujte stav synchronizace nového pohotovostního režimu [5432].
Krok 3. Otevřete nový pohotovostní režim [5432] jako primární vytvořením spouštěcího souboru nebo povýšením pg_ctl.

[postgres@localhost:/opt/PostgreSQL/9.3~]$ touch /tmp/primary_131_down.txt

Krok 4 Restart zastavil nový primární [5433] jako nový pohotovostní režim.

[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

Můžete ověřit protokoly nového pohotovostního režimu.

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

Velmi pěkné, bez dlouhého času jsme vyměnili povinnosti primárních a pohotovostních serverů. Můžete si dokonce všimnout nárůstu ID časové osy z protokolů pro každou propagaci.

Stejně jako ostatní všechny mé příspěvky jsou součástí sdílení znalostí, jakékoli komentáře nebo opravy jsou velmi vítány. 🙂


  1. Vložte časové razítko do databáze pomocí ContentValues

  2. Připojení k databázi MySQL v .NET

  3. Jak spustit SQL Server 2017 a 2019 současně na počítači Mac

  4. Jak funguje funkce LPAD() v MySQL