Správa vysoké dostupnosti (HA) ve vašem hostování PostgreSQL je velmi důležitým tématem, aby bylo zajištěno, že si clustery nasazení databází udrží výjimečnou provozuschopnost a vysoký provozní výkon, takže vaše data budou vaší aplikaci vždy k dispozici. V dřívějším příspěvku na blogu jsme vám představili konfiguraci vysoké dostupnosti pro PostgreSQL pomocí replikace streamování a nyní vám ukážeme, jak nejlépe spravovat vysokou dostupnost na straně klienta.
K dispozici je několik nástrojů pro správu vysoké dostupnosti (HA) vašich implementačních clusterů PostgreSQL pomocí streamingové replikace. Tato řešení nabízejí funkce automatického převzetí služeb při selhání, monitorování dostupnosti a stavu systému, replikaci, správu uživatelů a další užitečné administrativní úlohy v případech použití databází Postgres. Některá z předních open source řešení zahrnují:
-
Automatické převzetí služeb při selhání PostgreSQL od ClusterLabs
-
Replication Manager for PostgreSQL Clusters od repmgr (2ndQuadrant)
-
Patroni by Zalando
Každý nástroj poskytuje svůj vlastní způsob správy vysoce dostupných clusterů PostgreSQL. V naší třídílné sérii příspěvků o HA pro PostgreSQL se podělíme o přehled, předpoklady a výsledky práce a testů pro každý z těchto tří nástrojů. Zde v části 1 se hluboce ponoříme do řešení PAF od ClusterLabs.
- Správa vysoké dostupnosti v PostgreSQL – Část II:Správce replikací
- Správa vysoké dostupnosti v PostgreSQL – Část III:Patroni
Jak spravovat vysokou dostupnost vaší PostgreSQL databáze?
PostgreSQL Automatic Failover (PAF) je řešení pro správu vysoké dostupnosti PostgreSQL od ClusterLabs. Využívá synchronní replikaci Postgres, aby bylo zaručeno, že se v době operace převzetí služeb při selhání neztratí žádná data. Využívá populární, průmyslový standard Pacemaker a Corosync stack. Díky aplikacím Pacemaker a Corosync společně budete moci detekovat selhání databáze PostgreSQL v systému a podle toho jednat.
Pacemaker je služba schopná spravovat mnoho zdrojů, a to s pomocí jejich agentů zdrojů. Agenti zdrojů pak mají odpovědnost za zacházení s konkrétním zdrojem, za to, jak by se měli chovat, a informovat Pacemaker o svých výsledcích.
Vaše implementace agenta prostředků musí odpovídat specifikaci Open Cluster Framework (OCF). Tato specifikace definuje chování agentů zdrojů a implementaci metod, jako je zastavení, spuštění, povýšení, snížení úrovně a interakce s Pacemakerem.
PAF je agent zdrojů OCF pro Postgres napsaný v Perlu. Jakmile je váš databázový klastr vytvořen pomocí interní streamingové replikace, PAF je schopen zpřístupnit Pacemakerovi aktuální stav instance PostgreSQL na každém z uzlů databází:master, slave, stop, catching up, load balancer atd.
Jak funguje automatické převzetí služeb při selhání Postgres
PAF komunikuje s Pacemakerem ohledně stavu clusteru a monitoruje fungování databáze PostgreSQL. V případě selhání informuje Pacemaker, a pokud není šance na obnovení aktuálního masteru, spustí volbu mezi jedním z aktuálních pohotovostních databázových serverů. Se zavedeným robustním kardiostimulátorem bude Postgres Automatic Failover provádět akce správy, jako je spuštění, zastavení, monitorování a převzetí služeb při selhání na všech uzlech databází Postgres.
Správa vysoké dostupnosti v PostgreSQL – Část I:Automatické převzetí služeb při selhání od ClusterLabsClick To Tweet
Automatické převzetí služeb při selhání PostgreSQL pro konfiguraci vysoké dostupnosti (HA)
- PAF podporuje PostgreSQL verze 9.3 a vyšší.
- PAF nezodpovídá za vytvoření hlavního/standby PostgreSQL nebo jeho nastavení – před použitím PAF musíte vytvořit a nastavit replikaci streamování.
- PAF neupravuje žádné požadavky na konfiguraci nebo nastavení PostgreSQL. Vyžaduje však, aby uživatelé databáze dodržovali několik předpokladů, jako je:
- Slave musí být nakonfigurován jako aktivní pohotovostní režim. Aktivní pohotovostní podřízené uzly lze dotazovat jako databáze pouze pro čtení.
- Soubor šablony pro obnovení (výchozí:
/recovery.conf.pcmk) musí být poskytnut s níže uvedenými parametry: - pohotovostní_režim =zapnuto
- recovery_target_timeline =‘nejnovější’
- primary_conninfo musí mít definovaný parametr application_name a nastavený na název místního uzlu jako v Pacemaker.
- PAF odhaluje několik parametrů souvisejících se správou zdroje Postgres. To lze nakonfigurovat tak, aby vyhovovalo vašim požadavkům. Níže jsou uvedeny parametry:
- bindir: umístění binárních souborů PostgreSQL (výchozí:/usr/bin)
- pgdata: umístění PGDATA vaší instance (výchozí:/var/lib/pgsql/data)
- datadir: cestu k adresáři nastavenému v adresáři data_directory z vašeho souboru postgresql.conf
- pghost: adresář soketu nebo IP adresu, kterou chcete použít pro připojení k místní instanci (výchozí:/tmp)
- pgport: port pro připojení k místní instanci (výchozí:5432)
- recovery_template: místní šablonu, která bude zkopírována jako soubor PGDATA/recovery.conf. Tento soubor šablony musí existovat ve všech uzlech (výchozí:$PGDATA/recovery.conf.pcmk)
- start_opts: Další argumenty dané procesu Postgres při spuštění. Dostupné možnosti naleznete v části „postgres –help“. Užitečné, když soubor postgresql.conf není v datovém adresáři (PGDATA), např.:-c config_file=/etc/postgresql/9.3/main/postgresql.conf
- system_user: vlastník systému procesu vaší instance (výchozí:postgres)
- maxlag: maximální povolená prodleva v pohotovostním režimu, než u něj nastavíme negativní hlavní skóre
Profíci s automatickým selháním Postgres
- PAF poskytuje uživateli bezplatnou praktickou konfiguraci a nastavení PostgreSQL.
- PAF dokáže zpracovat selhání uzlu a spustit volby, když hlavní zařízení selže.
- Chování kvora lze vynutit v PAF.
- Bude poskytovat kompletní řešení správy databází s vysokou dostupností (HA) pro zdroj, včetně spouštění, zastavování a monitorování a zpracování scénářů izolace sítě.
- Je to distribuované řešení, které umožňuje správu libovolného uzlu z jiného uzlu.
Zápory automatického převzetí služeb při selhání Postgres
- PAF nezjistí, zda je pohotovostní uzel nesprávně nakonfigurován s neznámým nebo neexistujícím uzlem v konfiguraci obnovy. Uzel bude zobrazen jako podřízený, i když pohotovostní režim běží bez připojení k hlavnímu/kaskádovému pohotovostnímu uzlu.
- Vyžaduje otevření dalšího portu (výchozí 5405) pro komunikaci mezi kardiostimulátorem a komponentami Corosync pomocí protokolu UDP.
- Nepodporuje konfiguraci založenou na NAT.
- Žádná podpora pg_rewind.
Vysoká dostupnost pro testovací scénáře PostgreSQL
Provedli jsme několik testů, abychom v některých případech použití určili schopnost správy vysoké dostupnosti (ha) PostgreSQL pomocí PAF. Všechny tyto testy byly spuštěny za běhu aplikace a vkládání dat do databáze PostgreSQL. Aplikace byla napsána pomocí PostgreSQL Java JDBC Driver s využitím možnosti převzetí služeb při selhání připojení.
Pohotovostní testy serveru
| Sl. Ne | Scénář testu | Pozor |
|---|---|---|
| 1 | Zabijte proces PostgreSQL | Pacemaker vrátil proces PostgreSQL zpět do běžícího stavu. V aplikaci Writer nedošlo k žádnému přerušení. |
| 2 | Zastavte proces PostgreSQL | Pacemaker vrátil proces PostgreSQL zpět do běžícího stavu. V aplikaci Writer nedošlo k žádnému přerušení. |
| 3 | Restartujte server | Uzel záložního databázového serveru byl původně označen jako offline. Jakmile se server po restartu spustil, Pacemaker spustil databázi PostgreSQL a server byl označen jako online. Pokud by bylo oplocení povoleno, uzel by nebyl automaticky přidán do clusteru. V aplikaci Writer nedošlo k žádnému přerušení. |
| 4 | Zastavit proces kardiostimulátoru | Zastaví také proces PostgreSQL a uzel serveru bude označen jako offline. V aplikaci Writer nedošlo k žádnému přerušení. |
Testy hlavního/primárního serveru
| Sl. Ne | Testovací scénář | Pozor |
| 1 | Zabijte proces PostgreSQL | Pacemaker vrátil proces PostgreSQL zpět do běžícího stavu. Primární volby byly obnoveny během prahové doby, a proto nebyly spuštěny volby. Zapisovací aplikace byla mimo provoz asi 26 sekund. |
| 2 | Zastavte proces PostgreSQL | Pacemaker vrátil proces PostgreSQL zpět do běžícího stavu. Primární volby byly obnoveny během prahové doby, a proto nebyly spuštěny volby. V aplikaci Writer došlo k výpadku přibližně 26 sekund. |
| 3 | Restartujte server | Volby byly spuštěny kardiostimulátorem po prahové době, po kterou nebyl master k dispozici. Nejvhodnější pohotovostní server byl povýšen jako nový hlavní server. Jakmile se po restartu objevil starý hlavní server, byl přidán zpět do klastru databáze jako pohotovostní režim. Pokud by bylo oplocení povoleno, uzel by nebyl automaticky přidán do clusteru. Služba Write Application Service byla asi 26 sekund mimo provoz. |
| 4 | Zastavit proces kardiostimulátoru | Zastaví také proces PostgreSQL a server bude označen jako offline. Budou spuštěny volby a bude zvolen nový mistr. V aplikaci Writer došlo k výpadku. |
Testy izolace sítě
| Sl. Ne | Testovací scénář | Pozor |
| 1 | Síť izoluje záložní server od ostatních serverů | Provoz Corosync byl na pohotovostním serveru zablokován. Server byl označen jako offline a služba PostgreSQL byla vypnuta kvůli zásadám kvora. V aplikaci Writer nedošlo k žádnému přerušení. |
| 2 | Síť izoluje hlavní server od ostatních serverů (scénář s rozděleným mozkem) | Provoz Corosync byl na hlavním serveru zablokován. Služba PostgreSQL byla vypnuta a hlavní server byl označen jako offline kvůli zásadám kvora. Ve většinovém oddílu byl zvolen nový mistr. V aplikaci Writer došlo k výpadku. |
Různé testy
| Sl. Ne | Testovací scénář | Pozor |
| 1 | Degradujte cluster vypnutím všech záložních serverů. | Když vypadly všechny záložní servery, služba PostgreSQL na hlavním serveru byla zastavena kvůli zásadám kvora. Po tomto testu, kdy byly všechny záložní servery zapnuty, byl zvolen nový hlavní server. V aplikaci Writer došlo k výpadku. |
| 2 | Náhodně vypněte všechny servery jeden po druhém, počínaje hlavním serverem, a přiveďte je všechny zpět ve stejnou dobu | Všechny servery se spustily a připojily se ke clusteru. Byl zvolen nový mistr. V aplikaci Writer došlo k výpadku. |
Je PAF řešením pro PostgreSQL High Availability?
Automatické převzetí služeb při selhání Postgresu poskytuje několik výhod při práci s vysokou dostupností PostgreSQL (HA) v mnoha případech použití. PAF používá převzetí služeb při selhání IP adresy místo restartování pohotovostního režimu pro připojení k novému hlavnímu serveru během události převzetí služeb při selhání. To se ukazuje jako výhodné ve scénářích, kdy uživatel nechce restartovat pohotovostní uzly. PAF také potřebuje velmi málo ručního zásahu a spravuje celkový stav všech zdrojů databází Postgres. Jediným případem, kdy je vyžadován ruční zásah, je případ odchylky dat na časové ose, kdy se uživatel může rozhodnout použít pg_rewind.
V části 1 jsme probrali možnosti a fungování PostgreSQL Automatic Failover (PAF) od ClusterLabs a v části 2 probereme stejné aspekty vysoké dostupnosti pomocí Replication Manager pro clustery PostgreSQL (repmgr) od 2ndQuadrant. Nezapomeňte se vrátit do 3. části, kde se také budeme věnovat Patroni by Zalando a porovnat všechna tři řešení s otevřeným zdrojovým kódem, abychom vám pomohli určit nejvhodnější řešení pro vaši aplikaci.
V blogu 1. části jsme diskutovali o možnostech, osvědčených postupech a fungování PAF od ClusterLabs a v příspěvku na blogu v 2. části diskutujte o stejném tématu o aspektech vysoké dostupnosti pomocí Replication Manager pro clustery Postgresql (repmgr) od 2ndQuadrant. Nezapomeňte se znovu podívat na náš blogový příspěvek ve 3. části, kde se také budeme věnovat Patroni by Zalando a porovnat všechna tři řešení s otevřeným zdrojovým kódem, abychom vám pomohli určit osvědčené postupy a ideální řešení pro vaše podnikové aplikace.
