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

Správa vysoké dostupnosti v PostgreSQL – Část III:Patroni

V našich předchozích příspěvcích na blogu jsme diskutovali o možnostech a fungování PostgreSQL Automatic Failover (PAF) od Cluster Labs a Replication Manager (repmgr) od 2ndQuadrant. V posledním příspěvku této série zkontrolujeme poslední řešení, Patroni by Zalando, a porovnáme všechna tři na konci, abyste mohli určit, který rámec vysoké dostupnosti je nejlepší pro vaše hostingové nasazení PostgreSQL.

  • 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 II:Správce replikací

Patroni pro PostgreSQL

Patroni vznikl jako fork of Governor, projekt od Compose. Jedná se o open-source sadu nástrojů napsanou v Pythonu pro správu vysoké dostupnosti clusterů PostgreSQL. Namísto budování vlastního protokolu konzistence Patroni chytře využívá model konzistence, který poskytuje Distributed Configuration Store (DCS). Podporuje také další řešení DCS, jako je Zookeeper, etcd, Consul a Kubernetes.

Patroni zajišťuje kompletní nastavení klastrů PostgreSQL HA, včetně streamování replikace. Podporuje různé způsoby vytváření pohotovostního uzlu a funguje jako šablona, ​​kterou lze přizpůsobit vašim potřebám.

Tento nástroj bohatý na funkce odhaluje své funkce prostřednictvím rozhraní REST API a také pomocí nástroje příkazového řádku s názvem patronictl. Podporuje integraci s HAProxy pomocí jeho API pro kontrolu stavu pro vyrovnávání zátěže.

Patroni také podporuje upozornění na události pomocí zpětných volání, což jsou skripty spouštěné určitými akcemi. Umožňuje uživatelům provádět jakékoli akce údržby tím, že poskytuje funkci pozastavení/obnovení. Funkce podpory Watchdog činí rámec ještě robustnějším.

Jak to funguje

Zpočátku je třeba nainstalovat binární soubory PostgreSQL a Patroni. Jakmile to uděláte, budete také muset nastavit konfiguraci HA DCS. Všechny potřebné konfigurace pro bootstrap clusteru musí být specifikovány v konfiguračním souboru yaml a Patroni tento soubor použije pro inicializaci. Na prvním uzlu Patroni inicializuje databázi, získá zámek vůdce z DCS a zajistí, že uzel běží jako hlavní.

Dalším krokem je přidání uzlů v pohotovostním režimu, pro které Patroni nabízí několik možností. Ve výchozím nastavení používá Patroni pg_basebackup k vytvoření pohotovostního uzlu a také podporuje vlastní metody jako WAL-E, pgBackRest, Barman a další pro vytvoření pohotovostního uzlu. Patroni velmi usnadňuje přidání záložního uzlu a zvládá všechny úlohy bootstrapingu a nastavení vaší streamovací replikace.

Správa vysoké dostupnosti v #PostgreSQL – Část III:Patroni vs. PAF vs. repmgrClick To Tweet

Jakmile bude nastavení vašeho clusteru dokončeno, bude Patroni cluster aktivně sledovat a zajistit, aby byl v dobrém stavu. Hlavní uzel obnovuje zamykání vodítka každých ttl sekund (výchozí:30 sekund). Když se hlavnímu uzlu nepodaří obnovit vodící zámek, Patroni spustí volbu a uzel, který získá vodící zámek, bude zvolen jako nový master.

Jak zvládá scénář rozděleného mozku?

V distribuovaném systému hraje konsensus důležitou roli při určování konzistence a Patroni používá DCS k dosažení konsenzu. Pouze uzel, který drží vodící zámek, může být master a vodící zámek se získá prostřednictvím DCS. Pokud hlavní uzel nedrží zámek lídra, bude Patroni okamžitě degradován, aby běžel v pohotovostním režimu. Tímto způsobem může v libovolném okamžiku v systému běžet pouze jeden hlavní server.

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

  • Patroni potřebuje python 2.7 a vyšší.
  • Musí být nainstalován DCS a jeho specifický modul python. Pro testovací účely lze DCS nainstalovat na stejné uzly, na kterých běží PostgreSQL. Ve výrobě však musí být DCS instalován na samostatných uzlech.
  • Konfigurační soubor yaml musí být přítomen s tímto nastavením vysoké úrovně konfigurace:

    Globální/Univerzální
    To zahrnuje konfiguraci, jako je název hostitele (název), který musí být pro klastr jedinečný, název klastru (rozsah) a cesta pro uložení konfigurace v DCS (jmenný prostor).

    Protokol
    Nastavení protokolu specifická pro Patroni včetně úrovně, formátu, file_num, file_size atd.

    Konfigurace bootstrapu
    Toto je globální konfigurace pro klastr, který bude zapsán do DCS. Tyto konfigurační parametry lze změnit pomocí Patroni API nebo přímo v DCS. Konfigurace bootstrapu zahrnuje metody vytváření pohotovostního režimu, parametry initdb, post inicializační skript atd. Obsahuje také konfiguraci časových limitů, parametry pro rozhodování o použití funkcí PostgreSQL, jako jsou replikační sloty , synchronní režim atd. Tato sekce bude zapsána do ///config daného konfiguračního úložiště po inicializaci nového clusteru.

    PostgreSQL
    Tato sekce obsahuje parametry specifické pro PostgreSQL, jako je autentizace, cesty k adresářům pro data, binární a konfigurační, naslouchací IP adresa atd.

    REST API
    Tato část obsahuje konfiguraci specifickou pro Patroni týkající se REST API, jako je adresa naslouchání, ověřování, SSL atd.

    Konzul
    Nastavení specifická pro Consul DCS.

    Etcd
    Nastavení specifická pro Etcd DCS.

    Vystavovatel
    Nastavení specifická pro Exhibitor DCS.

    Kubernetes
    Nastavení specifická pro Kubernetes DCS.

    ZooKeeper
    Nastavení specifická pro ZooKeeper DCS.

    Hlídací pes
    Nastavení specifická pro Watchdog.

Profíci Patroni

  • Patroni umožňuje úplné nastavení clusteru.
  • Podporuje REST API a integraci HAproxy.
  • Podporuje upozornění na události prostřednictvím skriptů zpětných volání spouštěných určitými akcemi.
  • Využívá DCS ke konsenzu.

Zápory patroni

  • Patroni nezjistí nesprávnou konfiguraci pohotovostního režimu 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.
  • Uživatel se musí starat o nastavení, správu a upgrade softwaru DCS.
  • Vyžaduje otevření více portů pro komunikaci komponent:
    • Port REST API pro Patroni
    • Minimálně 2 porty pro DCS

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

Provedli jsme několik testů správy PostgreSQL HA pomocí Patroni. Všechny tyto testy byly provedeny 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 Patroni vrátil proces PostgreSQL zpět do běžícího stavu.

  • Nedošlo k žádnému přerušení aplikace Writer.
2 Zastavte proces PostgreSQL Patroni vrátil proces PostgreSQL zpět do běžícího stavu.

  • Nedošlo k žádnému přerušení aplikace Writer.
3 Restartujte server Patroni je třeba po restartu spustit, pokud není nakonfigurován tak, aby se při restartu nespustil. Jakmile byl Patroni spuštěn, spustil proces PostgreSQL a nastavil pohotovostní konfiguraci.

  • Nedošlo k žádnému přerušení aplikace Writer.
4 Zastavte proces Patroni
  • Proces PostgreSQL to nezastavilo.
  • seznam patronictl nezobrazil tento server.
  • Nedošlo k žádnému přerušení aplikace Writer.

V zásadě tedy musíte sledovat stav procesu Patroni – jinak to povede k problémům.

Testy hlavního/primárního serveru

Sl. Ne Testovací scénář Pozor
1 Zabijte proces PostgreSQL Patroni vrátil proces PostgreSQL zpět do běžícího stavu. Patroni běžící na tomto uzlu měl primární zámek, takže volby nebyly spuštěny.

  • Došlo k výpadku aplikace Writer.
2 Zastavte proces PostgreSQL a obnovte jej ihned po vypršení platnosti kontroly stavu Patroni vrátil proces PostgreSQL zpět do běžícího stavu. Patroni běžící na tomto uzlu měl primární zámek, takže volby nebyly spuštěny.

  • Došlo k výpadku aplikace Writer.
3 Restartujte server Došlo k selhání a jeden z pohotovostních serverů byl po získání zámku zvolen jako nový hlavní server. Když byl Patroni spuštěn na starém masteru, vrátil starý master nahoru a provedl pg_rewind a začal sledovat nový master.T

  • Došlo k výpadku aplikace Writer.
4 Zastavte/zabijte proces Patroni
  • Jeden z pohotovostních serverů získal zámek DCS a stal se hlavním tím, že se povýšil.
  • Starý master stále běžel a to vedlo ke scénáři s více mastery. Aplikace stále zapisovala do starého mistra.
  • Jakmile byla Patroni spuštěna na staré předloze, převinula starou předlohu (use_pg_rewind byla nastavena na hodnotu true) na novou hlavní časovou osu a lsn a začala sledovat novou hlavní stránku.

Jak můžete vidět výše, je velmi důležité sledovat stav procesu Patroni na masteru. Pokud tak neučiníte, může to vést ke scénáři s více hlavními servery a potenciální ztrátě dat.

Testy izolace sítě

Sl. Ne Testovací scénář Pozor
1 Síť – izolujte hlavní server od ostatních serverů Komunikace DCS byla pro hlavní uzel zablokována.

  • PostgreSQL byl degradován na hlavním serveru.
  • Ve většinovém oddílu byl zvolen nový mistr.
  • Došlo k výpadku aplikace Writer.
2 Síť – izolujte záložní server od ostatních serverů Komunikace DCS byla pro pohotovostní uzel zablokována.

  • Služba PostgreSQL byla spuštěna, ale uzel nebyl zvažován pro volby.
  • V aplikaci Writer nedošlo k žádnému přerušení.

Jaký je nejlepší rámec PostgreSQL HA?

Patroni je cenný nástroj pro správce databází PostgreSQL (DBA), protože provádí komplexní nastavení a monitorování clusteru PostgreSQL. Flexibilita výběru DCS a vytvoření pohotovostního režimu je výhodou pro koncového uživatele, protože si může vybrat metodu, která mu vyhovuje.

Rozhraní REST API, integrace HaProxy, podpora Watchdog, zpětná volání a jeho správa bohatá na funkce činí z Patroni nejlepší řešení pro správu PostgreSQL HA.

Testování rámce PostgreSQL HA:PAF vs. repmgr vs. Patroni

Níže je zahrnuta obsáhlá tabulka s podrobnými výsledky všech testů, které jsme provedli na všech třech frameworkech – PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) a Patroni.

Pohotovostní testy serveru

Scénář testu Automatické převzetí služeb při selhání PostgreSQL (PAF) Správce replikací (repmgr) Patroni
Zabijte proces PostgreSQL Pacemaker vrátil proces PostgreSQL zpět do běžícího stavu.

  • Nedošlo k žádnému přerušení aplikace Writer.
 Pohotovostní server byl označen jako neúspěšný. Pro opětovné spuštění procesu PostgreSQL byl vyžadován ruční zásah.

  • Nedošlo k žádnému přerušení aplikace Writer.
 Patroni vrátil proces PostgreSQL zpět do běžícího stavu.

  • Nedošlo k žádnému přerušení aplikace Writer.
Zastavte proces PostgreSQL Pacemaker vrátil proces PostgreSQL zpět do běžícího stavu.

  • Nedošlo k žádnému přerušení aplikace Writer.
 Pohotovostní server byl označen jako neúspěšný. Pro opětovné spuštění procesu PostgreSQL byl vyžadován ruční zásah.

  • Nedošlo k žádnému přerušení aplikace Writer.
 Patroni vrátil proces PostgreSQL zpět do běžícího stavu.

  • Nedošlo k žádnému přerušení aplikace Writer.
Restartujte server Pohotovostní server byl původně označen jako offline. Jakmile se server po restartu objevil, Pacemaker spustil PostgreSQL a server byl označen jako online. Pokud by bylo oplocení povoleno, uzel by nebyl automaticky přidán do clusteru.

  • Nedošlo k žádnému přerušení aplikace Writer.
 Pohotovostní server byl označen jako neúspěšný. Jakmile se server po restartu spustil, PostgreSQL se spustil ručně a server byl označen jako spuštěný.

  • Nedošlo k žádnému přerušení aplikace Writer.
 Patroni je třeba spustit po restartu, pokud není nakonfigurován tak, aby se nespustil při restartu. Jakmile byl Patroni spuštěn, spustil proces PostgreSQL a nastavil pohotovostní konfiguraci.

  • Nedošlo k žádnému přerušení aplikace Writer.
Zastavit proces agenta rámce Agent:kardiostimulátor

  • Proces PostgreSQL byl zastaven a označen jako offline.
  • Nedošlo k žádnému přerušení aplikace Writer.
 Agent: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ěží.
  • Nedošlo k žádnému přerušení aplikace Writer.
 Agent:patroni

  • Proces PostgreSQL to nezastavilo.
  • seznam patronictl nezobrazil tento server.
  • Nedošlo k žádnému přerušení aplikace Writer.

Testy hlavního/primárního serveru

Scénář testu Automatické převzetí služeb při selhání PostgreSQL (PAF) Správce replikací (repmgr) Patroni
Zabijte proces PostgreSQL Pacemaker vrátil proces PostgreSQL zpět do běžícího stavu. Primární se podařilo obnovit během prahové doby, a proto volby nebyly spuštěny.

  • Došlo k výpadku aplikace Writer.
 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 záložní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 následovat, jakmile oznámení obdrží. Pro opětovné spuštění procesu postgreSQL byl vyžadován ruční zásah.

  • Došlo k výpadku aplikace Writer.
 Patroni vrátil proces PostgreSQL zpět do běžícího stavu. Patroni běžící na tomto uzlu měl primární zámek, a proto volba nebyla spuštěna.

  • Došlo k výpadku aplikace Writer.
Zastavte proces PostgreSQL a vraťte jej zpět ihned po vypršení platnosti kontroly stavu Pacemaker vrátil proces PostgreSQL zpět do běžícího stavu. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back.Cluster was left in an indeterminate state and manual intervention was required.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. Nejvhodnější pohotovostní server byl povýšen jako nový hlavní server. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.

  • There was downtime in the writer application.
 repmgrd started election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was run to add the server back to the cluster.

  • There was downtime in the writer application.
 Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.

  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
 Agent:repmgrd

  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
 Agent:patroni

  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Testy izolace sítě

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.

  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
 All servers have the same value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • The eligible standby was promoted, but the PostgreSQL process was still running on the old master node.
  • There were two nodes running as master. Manual intervention was required after the network isolation was corrected.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had location different from that of the primary.
  • repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.
 DCS communication was blocked for master node.

  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.

  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
 DCS communication was blocked for the standby node.

  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.


  1. Jak změnit heslo root mysql

  2. Převést číslo měsíce na název měsíce v SQL Server (T-SQL)

  3. Podmínka počtu PostgreSQL Where

  4. Rails:Chyba při instalaci pg gem