Správa vysoké dostupnosti v PostgreSQL – Část II:Správce replikací

Nasazujete PostgreSQL v cloudu a chcete porozumět svým možnostem, jak dosáhnout vysoké dostupnosti? V našem předchozím příspěvku na blogu Správa vysoké dostupnosti v PostgreSQL – část I jsme diskutovali o možnostech a fungování PostgreSQL Automatic Failover (PAF) od ClusterLabs. V části II vám představujeme alternativní nástroj s otevřeným zdrojovým kódem, Replication Manager od 2ndQuadrant, který bude těsně následovat část III, kde se ponoříme do naší třetí alternativy, Patroni by Zalando.

Správa vysoké dostupnosti v PostgreSQL – Část I:Automatické převzetí služeb při selhání PostgreSQL
Správa vysoké dostupnosti v PostgreSQL – Část III:Patroni

Správce replikací (repmgr)

repmgr je sada nástrojů s otevřeným zdrojovým kódem vyvinutá společností 2ndQuadrant pro správu replikace a převzetí služeb při selhání vašich clusterů PostgreSQL. Poskytuje nástroje pro nastavení, konfiguraci, správu a monitorování replikace PostgreSQL a také vám umožňuje provádět ruční přepínání a přepnutí při selhání pomocí nástroje repmgr. Tento bezplatný nástroj podporuje a vylepšuje vestavěnou streamovací replikaci PostgreSQL.

Správce replikací poskytuje dva hlavní nástroje pro správu replikace a převzetí služeb při selhání PostgreSQL.

repmgr

Nástroj pro rozhraní příkazového řádku, který vám umožňuje provádět různé administrativní úkoly.
repmgr vám umožňuje nastavit pohotovostní servery, podporovat pohotovostní režimy, přepínat a monitorovat stav vašeho clusteru PostgreSQL.
Poskytuje také možnost suchého spuštění pro téměř všechny administrativní příkazy.

repmgrd

Toto je démon, který:

Aktivně monitoruje clustery PostgreSQL a provádí potřebné akce na základě stavu clusteru.
Provádí automatické převzetí služeb při selhání v případě, že primární uzel selže, tím, že povýší nejvhodnější pohotovostní režim jako nový primární.
Poskytuje možnost sledovat a ukládat data související s výkonem replikace.
Poskytuje upozornění vyvoláním uživatelských skriptů pro registrované události.

Jak to funguje

repmrg spravuje nejen replikaci clusterů PostgreSQL, ale má také funkce pro nastavení záložních serverů pro replikaci. Po úvodní instalaci musíme provést změny v konfiguračním souboru repmgr (repmgr.conf) s požadovanými podrobnostmi na každém serveru. Když je server nakonfigurován, musí být registrován u repmgr pomocí příkazu repmgr primary/standby register. Nejprve se nastaví a zaregistruje primární uzel. Poté se vytvoří a nakonfigurují záložní servery pomocí příkazu repmgr standby clone, který klonuje pohotovostní uzel PostgreSQL z jiného serveru PostgreSQL.

Správce replikací využívá funkci rozšíření PostgreSQL a vytváří vlastní schéma v databázi clusteru pro ukládání informací souvisejících s clusterem. Instalace rozšíření a vytvoření schématu probíhá během registrace primárního serveru pomocí repmgr. Po dokončení nastavení lze pomocí nástroje repmgr provádět manuální administrativní operace, jako je podpora, sledování, přepínání atd. Pro operaci přepínání vyžaduje nastavení SSH bez hesla mezi uzly.

Automatické převzetí služeb při selhání lze nastavit pomocí repmgrd. repmgrd vyžaduje načtení sdílené knihovny ‚repmgr‘ v době spouštění serveru PostgreSQL. Název knihovny by měl být uveden v shared_preload_libraries konfigurační parametr v souboru postgresql.conf. Aby repmgrd fungovalo, failover=automatic parametr je třeba nastavit v souboru repmgr.conf. Jakmile jsou všechny tyto parametry nastaveny, démon repmgrd začne aktivně monitorovat cluster. Pokud dojde k nějaké chybě v primárním uzlu, pokusí se znovu připojit několikrát. Když selžou všechny pokusy o připojení k primárnímu zdroji, zvolí se nejvhodnější pohotovostní režim volbou jako nového primárního uživatele repmgrd.

repmgr také podporuje upozornění na události. Má sadu předdefinovaných událostí a ukládá každý výskyt těchto událostí do tabulky repmgr.events. repmgr umožňuje předávání upozornění na události do uživatelem definovaného programu nebo skriptu, který může provést další akci, jako je odeslání e-mailu nebo spuštění výstrahy. To se provádí nastavením příkazu event_notification_command parametr v repmgr.conf.

Jak to řeší scénář rozděleného mozku?

repmgr se vypořádává se scénáři rozděleného mozku pomocí místa parametr, kde by každý uzel měl specifikovat parametr umístění na základě datového centra, ve kterém je umístěn. V případě jakéhokoli rozdělení sítě repmgr zajistí propagaci uzlu, který je na stejném místě jako primární. Pokud v tomto umístění nenajde žádný uzel, nebude propagovat žádný uzel v žádném umístění.

Zvládá také izolaci sítě v případě sudého počtu serverů v clusteru. To se provádí pomocí zvláštního uzlu nazývaného server svědků. Server svědků je uzel, který je brán v úvahu pouze pro většinu hlasů. Na tomto serveru nebude žádná instalace PostgreSQL, a tudíž nebude hrát žádnou roli v replikaci.

Existují nějaké požadavky na nastavení?

repmgr bude vyžadovat vyhrazenou databázi a uživatele s oprávněními superuživatele. Existuje však také možnost poskytnout superuživatele, pokud nechcete dát superuživateli přístup k uživateli repmgr.
Pokud chcete, aby repmgr zkopíroval konfigurační soubory, které jsou umístěny mimo datový adresář PostgreSQL, a/nebo otestoval funkci přepínání, budete také potřebovat připojení SSH bez hesla mezi oběma servery a rsync by měl být nainstalován.
Pokud chcete ke spuštění, zastavení, opětovnému načtení a restartování použít jiné příkazy založené na službě než pg_ctl (které používá repmgr), můžete je zadat v repmgr konfigurační soubor (repmgr.conf).

Základní konfigurační parametry požadované v konfiguračním souboru repmgr jsou následující:

id_uzlu (int) – Jedinečné celé číslo větší než nula, které identifikuje uzel.název_uzlu (řetězec) – Doporučuje se použít libovolný (ale jedinečný) řetězec využívající název hostitele serveru nebo jiný identifikátor jednoznačně spojený se serverem, aby nedošlo k záměně.

conninfo (řetězec) – Informace o připojení k databázi jako řetězec conninfo. Všechny servery v clusteru musí být schopny se připojit k místnímu uzlu pomocí tohoto řetězce.

data_directory (řetězec) – Datový adresář uzlu. To potřebuje repmgr k provádění operací, když instance PostgreSQL není spuštěna a neexistuje žádný jiný způsob, jak určit datový adresář.

odborníci repmgr

Repmgr poskytuje nástroje, které pomáhají nastavit primární a pohotovostní uzly a konfigurovat replikaci.
Nepoužívá pro komunikaci žádné další porty. Pokud chcete provést přepnutí, teprve potom bude nutné nakonfigurovat SSH bez hesla.
Poskytuje upozornění vyvoláním uživatelských skriptů pro registrované události.
Provádí automatické převzetí služeb při selhání v případě selhání primárního serveru.

zápory repmgr

repmgr nezjistí, zda je pohotovostní režim špatně nakonfigurován s neznámým nebo neexistujícím uzlem v konfiguraci obnovy. Uzel bude zobrazen jako pohotovostní, i když bude spuštěn bez připojení k primárnímu/kaskádovému pohotovostnímu uzlu.
Nelze načíst stav jiného uzlu z uzlu, kde je služba PostgreSQL mimo provoz. Neposkytuje tedy řešení distribuovaného ovládání.
Nezvládá obnovení stavu jednotlivých uzlů.

Správa vysoké dostupnosti v #PostgreSQL – Část II:Open Source repmgr Tool Click To Tweet

Scénáře testování vysoké dostupnosti

Provedli jsme několik testů správy vysoké dostupnosti PostgreSQL pomocí repmgr. 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í.

Pohotovostní testy serveru

Sl. Ne	Scénář testu	Pozor
1	Zabijte proces PostgreSQL	Pohotovostní server byl označen jako neúspěšný. V aplikaci Writer nedošlo k žádnému přerušení. K opětovnému spuštění procesu PostgreSQL byl vyžadován ruční zásah.
2	Zastavte proces PostgreSQL	Pohotovostní server byl označen jako neúspěšný. V aplikaci Writer nedošlo k žádnému přerušení. K opětovnému spuštění procesu PostgreSQL byl vyžadován ruční zásah.
3	Restartujte server	Pohotovostní server byl označen jako neúspěšný. Jakmile server po restartu přišel, PostgreSQL se spustil ručně a server byl označen jako spuštěný. V aplikaci Writer nedošlo k žádnému přerušení.
4	Zastavte proces repmgrd	Pohotovostní server nebude součástí situace automatického převzetí služeb při selhání. Bylo zjištěno, že služba PostgreSQL běží. 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	repmgrd spustil kontrolu stavu připojení primárního serveru na všech serverech v pohotovostním režimu na pevný interval. Když všechny pokusy selhaly, byly na všech pohotovostních serverech spuštěny volby. V důsledku voleb byl povýšen pohotovostní režim, který měl naposledy přijaté LSN. Pohotovostní servery, které prohrály volby, počkají na oznámení od nového hlavního uzlu a budou jej sledovat, jakmile oznámení obdrží. Došlo k výpadku aplikace Writer. K opětovnému spuštění procesu PostgreSQL byl vyžadován ruční zásah.
2	Zastavte proces PostgreSQL a obnovte jej ihned po vypršení platnosti kontroly stavu	repmgrd spustil kontrolu stavu připojení primárního serveru na všech serverech v pohotovostním režimu na pevný interval. Když všechny pokusy selhaly, byly na všech pohotovostních uzlech spuštěny volby. Nově zvolený hlavní server však neupozornil stávající záložní servery, protože starý hlavní server byl zpět. Cluster byl ponechán v neurčitém stavu a byl vyžadován ruční zásah.
3	Restartujte server	repmgrd zahájil volby, když kontrola stavu hlavního připojení selhala na všech serverech v pohotovostním režimu. Byl povýšen vhodný pohotovostní režim. Když se tento server vrátil, nepřipojil se ke clusteru a byl označen jako neúspěšný. Byl spuštěn příkaz repmgr node rejoin pro přidání serveru zpět do clusteru. V aplikaci Writer došlo k výpadku.
4	Zastavte proces repmgr	Primární server nebude součástí situace automatického převzetí služeb při selhání. Bylo zjištěno, že služba PostgreSQL běží. V aplikaci Writer nedošlo k žádnému přerušení.

Testy izolace sítě

Sl. Ne	Testovací scénář	Pozor
1	Síť izoluje primární server od ostatních serverů (všechny mají stejnou hodnotu pro umístění v konfiguraci repmgr)	repmgrd zahájil volby, když kontrola stavu hlavního připojení selhala na všech serverech v pohotovostním režimu. Vhodný pohotovostní režim byl povýšen, ale proces PostgreSQL stále běžel na starém hlavním uzlu. Byly tam dva uzly spuštěné jako hlavní. Po opravě izolace sítě byl vyžadován ruční zásah.
2	Síť izoluje primární server od ostatních serverů (servery v pohotovostním režimu mají stejnou hodnotu pro umístění, ale primární měl jinou hodnotu pro umístění v konfiguraci repmgr)	repmgrd zahájil volby, když kontrola stavu hlavního připojení selhala na všech serverech v pohotovostním režimu. Nebyl však zvolen žádný nový hlavní server, protože záložní servery měly jiné umístění než primární. repmgrd přešel do sníženého režimu monitorování. PostgreSQL běžel na všech uzlech a v clusteru byl pouze jeden master.

Odvození

repmgr poskytuje několik příkazů pro nastavení a sledování replikace PostgreSQL. Je bohatý na funkce a také usnadňuje práci správce databáze (DBA). Nejedná se však o plnohodnotný nástroj pro správu vysoké dostupnosti, protože nebude spravovat zdroje. K zajištění správného stavu zdroje je nutný ruční zásah.

Takže v tomto příspěvku jsme diskutovali o možnostech a fungování Replication Manager od 2ndQuadrant. V našem dalším příspěvku probereme stejné aspekty vysoké dostupnosti pomocí Patroni by Zalando. Pro uživatele, kteří chtějí automatizovat svou vysokou dostupnost v cloudu, se podívejte na naše plně spravovaná řešení PostgreSQL na Azure a PostgreSQL na AWS.