Konfigurace PostgreSQL pro kontinuitu podnikání

Business Continuity for Databases

Obchodní kontinuita pro databáze znamená, že databáze musí být nepřetržitě funkční i během katastrof. Je bezpodmínečně nutné zajistit, aby byly produkční databáze pro aplikace neustále k dispozici i během katastrof, jinak by to mohlo být drahé. DBA, architekti by se museli ujistit, že databázová prostředí vydrží katastrofy a budou v souladu se SLA pro obnovu po havárii. Aby katastrofy neovlivnily dostupnost databáze, musí být databáze nakonfigurovány pro kontinuitu provozu.

Konfigurace databází pro kontinuitu podnikání zahrnuje spoustu architektur, plánování, navrhování a testování. Při navrhování a implementaci efektivní strategie obnovy databází po havárii přichází v úvahu mnoho faktorů, jako jsou datová centra a jejich geografická území včetně návrhu infrastruktury. To vysvětluje skutečnost, že „Kontinuita podnikání =Vyhněte se výpadkům během katastrof “.

Aby bylo zajištěno, že produkční databáze přežijí katastrofu, musí být nakonfigurována lokalita Disaster Recovery (DR). Produkční a DR místa musí být součástí dvou geograficky vzdálených datových center. To znamená, že v místě DR musí být pro každou produkční databázi nakonfigurována záložní databáze, aby se změny dat, ke kterým dojde v produkční databázi, okamžitě synchronizovaly s rezervní databází prostřednictvím transakčních protokolů. Toho lze dosáhnout pomocí funkce „Streaming Replication“ v PostgreSQL.

Co se musí stát, když produkční (nebo primární) databázi zasáhne katastrofa?

Když se produkční (primární) databáze zhroutí nebo přestane reagovat, musí být pohotovostní databáze povýšena na primární a aplikace musí být nasměrovány na nově povýšenou pohotovostní (novou primární) databázi a vše se musí dít automaticky v rámci určeného výpadku SLA. Tento proces se nazývá převzetí služeb při selhání.

Konfigurace PostgreSQL pro vysokou dostupnost

Jak bylo řečeno výše, aby bylo zajištěno, že PostgreSQL vyhovuje obnově po havárii, musí být nejprve nakonfigurován s replikací streamování (hlavní + záložní databáze) a s automatickými funkcemi pohotovostního režimu/přepnutí při selhání. Podívejme se nejprve na to, jak nakonfigurovat replikaci streamování a poté na proces „přepnutí při selhání“.

Konfigurace pohotovostní databáze (replikace datového proudu)

Streamová replikace je vestavěná funkce PostgreSQL, která zajišťuje replikaci dat z primární do pohotovostní databáze prostřednictvím záznamů WAL a podporuje asynchronní i synchronní metody replikace. Tento způsob replikace je poměrně spolehlivý a vhodný pro prostředí vyžadující vysoce výkonnou replikaci v reálném čase.

Konfigurace pohotovostního režimu streamování je velmi jednoduchá. Prvním krokem je zajistit, aby konfigurace primární databáze byly následující:

Povinné konfigurace primární databáze

Ujistěte se, že následující parametry jsou nakonfigurovány v postgresql.conf na primární databázi. Provedení následujících změn by vyžadovalo restart databáze.

wal_level=logical

Parametr wal_level zajišťuje, že informace požadované pro replikaci jsou zapsány do souborů WAL.

max_wal_senders=1 (or any number more than 0)

Záznamy WAL jsou odesílány procesem odesílatele wal z primární databáze do záložní databáze. Výše uvedený parametr tedy musí být nakonfigurován na minimálně 1. Pokud je vyžadováno více odesílatelů wal, je vyžadována více než hodnota 1.

Povolit archivaci WAL

Neexistuje žádná pevná závislost na archivaci WAL pro streamování replikace. Důrazně se však doporučuje nakonfigurovat archivaci WAL, protože pokud se pohotovostní režim opozdí a pokud jsou požadované soubory WAL odstraněny z adresáře pg_xlog (nebo pg_wal), budou archivní soubory vyžadovány, aby se pohotovostní režim synchronizoval s primárním pokud ne, musí být pohotovostní režim přestavěn od nuly.

archive_mode=on
archive_command=<archive location>

Primární databáze musí být nakonfigurována tak, aby přijímala připojení z pohotovostního režimu.

Níže uvedená konfigurace musí být v pg_hba.conf

host    replication     postgres        <standby-database-host-ip>/32            trust

Nyní vytvořte zálohu primární databáze a obnovte ji na webu DR. Po dokončení obnovy vytvořte soubor recovery.conf v datovém adresáři s následujícím obsahem:

standby_mode=’on’
primary_conninfo=’host=<master-database-host-ip>, port=<master-database-port>, user=<replication-user>’
restore_command=’cp /database/wal_restore/%f %p’
trigger_file=’/database/promote_trigfile’
recovery_target_timeline=’latest’

Nyní spusťte pohotovostní databázi. Musí být povolena streamovaná replikace. Níže uvedená zpráva v souboru protokolu postgresql pohotovostní databáze potvrzuje, že replikace datového proudu úspěšně funguje:

2018-01-13 00:22:44 AEDT [4432]: [1] user=,db=,app=,client= LOG:  started streaming WAL from primary at 127/CD000000 on timeline 1
2018-01-13 00:22:44 AEDT [4268]: [5] user=,db=,app=,client= LOG:  redo starts at 127/CD380170

Z toho vyplývá, že je na místě plně funkční replikace streamování. Další krok k instalaci/konfiguraci repmgr. Předtím se podívejme na proces převzetí služeb při selhání.

Co je převzetí služeb při selhání?

K převzetí služeb při selhání dochází, když se primární databáze stane zcela nedostupnou kvůli havárii. Během procesu převzetí služeb při selhání bude pohotovostní databáze povýšena na novou primární databázi, aby aplikace mohly pokračovat v obchodních operacích.

Automatické převzetí služeb při selhání

Celý proces převzetí služeb při selhání musí proběhnout automaticky, aby byla zajištěna efektivní obchodní kontinuita, a toho lze dosáhnout pouze pomocí některých middlewarových nástrojů. Celá myšlenka je vyhnout se manuálnímu zásahu administrátorů, vývojářů.

Jedním z takových nástrojů, který pomáhá provádět automatické převzetí služeb při selhání, je „repmgr“.

Pojďme se podívat na repmgr a jeho schopnosti.

Repmgr

Repmgr je opensource nástroj vyvinutý společností 2nd Quadrant. Tento nástroj pomáhá provádět různé administrativní činnosti databáze, jako je vytváření a monitorování replikace PostgreSQL, včetně provádění automatizovaných činností přepnutí při selhání v případě havárie a také pomáhá provádět operace přepínání.

Repmgr je snadno instalovatelný nástroj a konfigurace také nejsou složité. Nejprve se podívejme na instalaci:

Instalace repmgr

Stáhněte si nástroj odtud.

Rozbalte tarball a proveďte instalaci, jak je uvedeno níže:

Nainstaloval jsem repmgr-4.2.0 na hostitele CentOS 7 a nainstaloval jsem repmgr proti PostgreSQL-11.1. Před instalací se ujistěte, že adresář PostgreSQL bin je součástí $PATH a adresář PostgreSQL lib je součástí $LD_LIBRARY_PATH. Abych pochopil, že repmgr je nainstalován proti PostgreSQL-11.1, níže zobrazujem výstup „make install“:

[[email protected] repmgr-4.2.0]# ./configure --prefix=/opt/repmgr-4.2
[[email protected] repmgr-4.2.0]# make
[[email protected] repmgr-4.2.0]# make install
Building against PostgreSQL 11
/bin/mkdir -p '/opt/pgsql-11.1/lib'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/bin'
/bin/install -c -m 755  repmgr.so '/opt/pgsql-11.1/lib/repmgr.so'
/bin/install -c -m 644 .//repmgr.control '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 644 .//repmgr--unpackaged--4.0.sql .//repmgr--4.0.sql .//repmgr--4.0--4.1.sql .//repmgr--4.1.sql .//repmgr--4.1--4.2.sql .//repmgr--4.2.sql  '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 755 repmgr repmgrd '/opt/pgsql-11.1/bin/'

Konfigurace repmgr pro automatické převzetí služeb při selhání

Než se podíváme na konfiguraci „repmgr“, musí být databáze nakonfigurovány pomocí streamingové replikace, kterou jsme viděli dříve. Pro začátek musí být obě databáze (primární i pohotovostní) nakonfigurovány pomocí následujícího parametru v postgresql.conf:

Primary

[[email protected] log]$ grep "shared_preload" /data/pgdata11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

Standby

[[email protected] log]$ grep "shared_preload" /data/pgdata-standby11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

Výše uvedený parametr umožňuje povolit démona „repmgrd“, který nepřetržitě běží na pozadí a monitoruje streamovanou replikaci. Bez tohoto parametru není možné provést automatické převzetí služeb při selhání. Změna tohoto parametru by vyžadovala restart databáze.
Dále vytvořte konfigurační soubor repmgr (řekněme s názvem repmgr.conf) pro obě databáze. Primární databáze musí mít konfigurační soubor s následujícím obsahem:

node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'

Umístěte soubor do datového adresáře, v tomto případě je to „/data/pgdata11“.

Konfigurační soubor pohotovostní databáze musí mít následující obsah:

node_id=2
node_name=node2
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2'
data_directory='/data/pgdata-standby11'

failover=automatic
promote_command='repmgr standby promote -f /data/pgdata-standby11/repmgr.conf'
follow_command='repmgr standby follow -f /data/pgdata-standby11/repmgr.conf --upstream-node-id=%n'

monitoring_history=yes
monitor_interval_secs=5

log_file='/data/pgdata-standby11/repmgr_logs/repmgr.log'
log_status_interval=5
log_level=DEBUG

promote_check_timeout=5
promote_check_interval=1

master_response_timeout=5
reconnect_attempts=5
reconnect_interval=10

Obě databáze musí být registrovány u repmgr.
Registrovat primární databázi

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata11/repmgr.conf primary register
INFO: connecting to primary database...
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registered

Zaregistrujte pohotovostní databázi

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf standby register --upstream-node-id=1
INFO: connecting to local node "node2" (ID: 2)
INFO: connecting to primary database
INFO: standby registration complete
NOTICE: standby node "node2" (id: 2) successfully registered

Spusťte níže uvedený příkaz a ujistěte se, že protokolování repmgr funguje.

[[email protected] ~]$ repmgrd -f /data/pgdata-standby11/repmgr.conf --verbose --monitoring-history
[2019-02-16 16:31:26] [NOTICE] using provided configuration file "/data/pgdata-standby11/repmgr.conf"
[2019-02-16 16:31:26] [WARNING] master_response_timeout/5: unknown name/value pair provided; ignoring
[2019-02-16 16:31:26] [NOTICE] redirecting logging output to "/data/pgdata-standby11/repmgr_logs/repmgr.log"

Pokud můžete pozorovat, nakonfiguroval jsem úroveň log_level na DEBUG, aby se generovalo podrobné protokolování v souboru repmgr.conf v pohotovostním režimu. Zkontrolujte protokoly o stavu replikace.
Zkontrolujte, zda replikace funguje podle očekávání pomocí repmgr:

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf cluster show
 ID | Name  | Role    | Status    | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-------------------------------------------------------------------------------
 1  | node1 | primary | * running |          | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2
 2  | node2 | standby |   running | node1    | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2

Výše uvedená zpráva potvrzuje, že replikace běží správně.

Nyní, když vypnu primární databázi, démon repmgrd by měl detekovat selhání primární databáze a měl by podpořit záložní databázi. Uvidíme, jestli se to stane - Primární databáze je zastavena:

[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stopped

Pohotovostní databáze musí být povýšena automaticky. Protokoly repmgr by ukázaly totéž:

fallback_application_name=repmgr is 2
[2019-02-14 17:09:23] [WARNING] unable to reconnect to node 1 after 5 attempts
[2019-02-14 17:09:23] [DEBUG] is_server_available(): ping status for host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2 is 0
[2019-02-14 17:09:23] [DEBUG] do_election(): electoral term is 1
[2019-02-14 17:09:23] [DEBUG] get_active_sibling_node_records():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name     FROM repmgr.nodes n    WHERE n.upstream_node_id = 1      AND n.node_id != 2      AND n.active IS TRUE ORDER BY n.node_id
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - closing open connections
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - unlinking
[2019-02-14 17:09:23] [DEBUG] do_election(): primary location is "default", standby location is "default"
[2019-02-14 17:09:23] [DEBUG] no other nodes - we win by default
[2019-02-14 17:09:23] [DEBUG] election result: WON
[2019-02-14 17:09:23] [NOTICE] this node is the only available candidate and will now promote itself
[2019-02-14 17:09:23] [DEBUG] get_node_record():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name   FROM repmgr.nodes n  WHERE n.node_id = 1
[2019-02-14 17:09:23] [INFO] promote_command is:
  "repmgr standby promote -f /data/pgdata-standby11/repmgr.conf"
WARNING: master_response_timeout/5: unknown name/value pair provided; ignoring
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl  -w -D '/data/pgdata-standby11' promote"
DETAIL: waiting up to 5 seconds (parameter "promote_check_timeout") for promotion to complete
DEBUG: setting node 2 as primary and marking existing primary as failed
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primary

Výše uvedené přesně znamená, že repmgr se nemohl připojit k primární databázi a po 5 neúspěšných pokusech je pohotovostní režim povýšen na novou primární databázi. Níže je uvedeno, co zobrazuje povýšené pohotovostní (nové primární) protokoly databáze:

2019-02-14 17:09:21 AEDT [20789]: [1] user=,db=,app=,client= FATAL:  could not connect to the primary server: could not connect to server: Connection refused
                Is the server running on host "xxx.xxx.xx.xx" and accepting
                TCP/IP connections on port 5432?
2019-02-14 17:09:23 AEDT [20506]: [7] user=,db=,app=,client= LOG:  received promote request
2019-02-14 17:09:23 AEDT [20506]: [8] user=,db=,app=,client= LOG:  redo done at 10F/5A335FF0
2019-02-14 17:09:23 AEDT [20506]: [9] user=,db=,app=,client= LOG:  last completed transaction was at log time 2019-02-14 17:08:38.350695+11
2019-02-14 17:09:23 AEDT [20506]: [10] user=,db=,app=,client= LOG:  selected new timeline ID: 2
2019-02-14 17:09:23 AEDT [20506]: [11] user=,db=,app=,client= LOG:  archive recovery complete
2019-02-14 17:09:24 AEDT [20507]: [1] user=,db=,app=,client= LOG:  checkpoint starting: force
2019-02-14 17:09:24 AEDT [20504]: [7] user=,db=,app=,client= LOG:  database system is ready to accept connections

Zmínil jsem pouze důležité parametry v konfiguračním souboru repmgr. Existuje mnoho dalších parametrů, které lze upravit tak, aby vyhovovaly různým požadavkům. Další důležité parametry jsou parametry replikace_lag_*, jak je uvedeno níže:

#replication_lag_warning=300            # repmgr node check --replication-lag
#replication_lag_critical=600           #

Repmgr by před podporou pohotovostního režimu zkontroloval prahové hodnoty výše uvedených parametrů. Pokud je zpoždění replikace kritické, propagace nebude pokračovat. Což je opravdu dobré, protože pokud dojde ke zpoždění v pohotovostním režimu, dojde ke ztrátě dat.

Aplikace musí zajistit, aby se znovu úspěšně připojily k nově podporovanému pohotovostnímu režimu v očekávaném časovém rámci. Nástroje pro vyrovnávání zatížení by měly schopnost odklonit připojení aplikace, když primární databáze přestane reagovat. Druhou alternativou by bylo použití middlewarových nástrojů, jako je PgPool-II, které zajistí úspěšné odklonění všech připojení.

Aby bylo zajištěno úspěšné nasazení architektury s vysokou dostupností v produkci, musí být provedeno důkladné testování celého procesu od začátku do konce. Podle mých zkušeností toto cvičení nazýváme DR DRILL. To znamená, že každých zhruba 6 měsíců by se provedla operace přepnutí, aby se zajistilo, že se pohotovostní režim úspěšně povýší a připojení aplikace se znovu úspěšně připojí k povýšenému pohotovostnímu režimu. Stávající primární se stane novým pohotovostním režimem. Jakmile je operace přechodu úspěšná, metriky jsou staženy, aby se zjistilo, zda jsou splněny smlouvy SLA.

Co je přechod?

Jak bylo vysvětleno výše, Přepnutí je plánovaná aktivita, při které se přepínají role Primární a Pohotovostní databáze. To znamená, že pohotovostní režim se stane primárním a primární se stane pohotovostním režimem. Pomocí repmgr toho lze dosáhnout. Níže je uvedeno, co dělá repmgr, když je vydán příkaz k přepnutí.

$ repmgr -f /etc/repmgr.conf standby switchover
    NOTICE: executing switchover on node "node2" (ID: 2)
    INFO: searching for primary node
    INFO: checking if node 1 is primary
    INFO: current primary node is 1
    INFO: SSH connection to host "node1" succeeded
    INFO: archive mode is "off"
    INFO: replication lag on this standby is 0 seconds
    NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
    NOTICE: stopping current primary node "node1" (ID: 1)
    NOTICE: issuing CHECKPOINT
    DETAIL: executing server command "pg_ctl -D '/data/pgdata11' -m fast -W stop"
    INFO: checking primary status; 1 of 6 attempts
    NOTICE: current primary has been cleanly shut down at location 0/0501460
    NOTICE: promoting standby to primary
    DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -D '/data/pgdata-standby11' promote"
    server promoting
    NOTICE: STANDBY PROMOTE successful
    DETAIL: server "node2" (ID: 2) was successfully promoted to primary
    INFO: setting node 1's primary to node 2
    NOTICE: starting server using  "pg_ctl -D '/data/pgdata11' restart"
    NOTICE: NODE REJOIN successful
    DETAIL: node 1 is now attached to node 2
    NOTICE: switchover was successful
    DETAIL: node "node2" is now primary
    NOTICE: STANDBY SWITCHOVER is complete

Co jiného umí repmgr?

• Repmgr může pomoci vybudovat záložní databáze od nuly
• Je možné sestavit více záložních databází s jedním spuštěným hlavním systémem
• Lze vytvořit kaskádové pohotovostní režimy, což je podle mého názoru výhodnější než konfigurace více pohotovostních režimů do jedné hlavní databáze

Co když primární i pohotovostní režim zmizí?

No, toto je situace, kdy podniky přemýšlejí o více pohotovostních instancích. Pokud jsou všechny pryč, pak jedinou cestou ven je obnovit databázi ze záloh. To je důvod, proč je nezbytná dobrá strategie zálohování. Zálohy musí být testovány a pravidelně ověřovány, aby bylo zajištěno, že zálohy jsou spolehlivé. Návrh infrastruktury pro zálohování musí být takový, že obnova a obnova záloh nesmí trvat dlouho. Proces obnovy a obnovy záloh musí být dokončen v rámci určené smlouvy SLA. SLA pro zálohy jsou navrženy z hlediska RTO (období obnovy) a RPO (objekt bodu obnovy). To znamená, RTO:čas potřebný k obnovení a obnovení zálohy musí být v rámci SLA a RPO:do kterého okamžiku byla obnova provedena, musí být přijatelné, jinými slovy je to tolerance ztráty dat a obecně podniky říkají 0 ztrátě dat tolerance.

Závěr

• Kontinuita podnikání pro PostgreSQL je důležitým požadavkem pro kritická databázová prostředí. Dosažení tohoto cíle vyžaduje spoustu plánování a nákladů.
• Zdroje a infrastruktura musí být optimálně využívány, aby byla zajištěna účinná strategie obnovy po havárii.
• Z hlediska nákladů mohou nastat problémy, kterým je třeba věnovat pozornost
• Pokud to rozpočet dovoluje, zajistěte, aby existovalo několik webů DR pro převzetí služeb při selhání
• V případě, že mají být zálohy obnoveny, zajistěte správnou strategii zálohování.