An dësem Artikel wäert ech Iech soen wéi mir d'Thema vun der PostgreSQL Feeler Toleranz ukomm sinn, firwat et fir eis wichteg gouf a wat um Enn geschitt ass.
Mir hunn en héich gelueden Service: 2,5 Millioune Benotzer weltwäit, 50K+ aktiv Benotzer all Dag. D'Servere sinn an Amazone an enger Regioun vun Irland lokaliséiert: 100+ verschidde Servere si permanent a Betrib, bal 50 vun hinnen mat Datenbanken.
De ganze Backend ass eng grouss monolithesch statesch Java Applikatioun déi eng persistent Websocket Verbindung mam Client hält. Wann e puer Benotzer gläichzäiteg um selwechte Bord schaffen, gesinn se all Ännerungen an Echtzäit, well mir all Ännerung an der Datebank ophuelen. Mir hunn ongeféier 10K Ufroe pro Sekonn un eis Datenbanken. Bei Peakbelaaschtung am Redis schreiwen mir 80-100K Ufroen pro Sekonn.
Firwat hu mir vu Redis op PostgreSQL gewiesselt
Am Ufank huet eise Service mat Redis geschafft, e Schlësselwäertlager deen all Daten am RAM vum Server späichert.
Virdeeler vu Redis:
- Héich Äntwert Vitesse, well alles gëtt an der Erënnerung gespäichert;
- Confortabel Backupsatellit a Replikatioun.
Nodeeler vu Redis fir eis:
- Et gi keng real Transaktiounen. Mir hu probéiert se op eisem Applikatiounsniveau ze imitéieren. Leider huet dëst net ëmmer gutt geschafft an huet e ganz komplexe Code geschriwwen.
- D'Quantitéit vun Daten ass limitéiert duerch d'Quantitéit un Erënnerung. Wéi d'Quantitéit vun den Donnéeën eropgeet, wäert d'Erënnerung wuessen, an um Enn lafe mir an d'Charakteristike vun der gewielter Instanz, déi an AWS erfuerdert eise Service ze stoppen fir den Instanztyp z'änneren.
- Et ass néideg dauernd e nidderegen latency Niveau ze halen, well Mir hunn eng ganz grouss Zuel vun Demanden. Den optimale Latenzniveau fir eis ass 17-20 ms. Op engem Niveau vun 30-40 ms kréie mir laang Äntwerten op eis Uwendungsufroen a Servicedegradatioun. Leider ass dëst eis am September 2018 geschitt, wéi ee vun de Fäll mat Redis aus irgendege Grënn eng latency krut déi 2 Mol méi héich war wéi soss. Fir de Problem ze léisen, hu mir de Service an der Mëtt vum Aarbechtsdag gestoppt fir ongeplangten Ënnerhalt an ersat déi problematesch Redis Instanz.
- Et ass einfach inkonsistent Donnéeën ze kréien och mat klenge Feeler am Code an dann vill Zäit ze verbréngen Code ze schreiwen fir dës Donnéeën ze fixéieren.
Mir hunn d'Nodeeler berücksichtegt a gemierkt datt mir op eppes méi bequem musse plënneren, mat normale Transaktiounen a manner Ofhängegkeet vun der latency. Mir hunn eis Fuerschung gemaach, vill Optiounen analyséiert a PostgreSQL gewielt.
Mir sinn elo 1,5 Joer an eng nei Datebank geplënnert an hunn nëmmen e klengen Deel vun den Donnéeën iwwerginn, also schaffe mir elo gläichzäiteg mat Redis a PostgreSQL. Méi Informatioun iwwer d'Etappe vun der Beweegung an der Wiessel vun Daten tëscht Datenbanken ass geschriwwen .
Wéi mir fir d'éischt ugefaang hunn ze plënneren, huet eis Applikatioun direkt mat der Datebank geschafft an op de Redis a PostgreSQL Master zougänglech gemaach. De PostgreSQL Cluster bestoung aus engem Master an enger Replika mat asynchroner Replikatioun. Dëst ass wéi den Datebank Workflow ausgesinn huet:
Ëmsetzung vun PgBouncer
Wärend mir geplënnert sinn, huet d'Produkt och entwéckelt: d'Zuel vun de Benotzer an d'Zuel vun de Serveren, déi mat PostgreSQL geschafft hunn, ass eropgaang, a mir hunn ugefaang aus Verbindungen ze lafen. PostgreSQL erstellt e separaten Prozess fir all Verbindung a verbraucht Ressourcen. Dir kënnt d'Zuel vun de Verbindungen bis zu engem gewësse Punkt erhéijen, soss besteet d'Chance datt d'Datebank net optimal funktionnéiert. Déi ideal Optioun an esou enger Situatioun wier e Verbindungsmanager ze wielen deen virun der Datebank steet.
Mir haten zwou Méiglechkeeten fir de Verbindungsmanager: Pgpool a PgBouncer. Awer déi éischt ënnerstëtzt net den Transaktiounsmodus fir mat der Datebank ze schaffen, also hu mir PgBouncer gewielt.
Mir hunn de folgenden Aarbechtsschema konfiguréiert: eis Applikatioun huet Zougang zu engem PgBouncer, hannert deem et PostgreSQL Masters sinn, an hannert all Master gëtt et eng Replika mat asynchroner Replikatioun.
Zur selwechter Zäit konnte mir net de ganze Betrag vun Daten am PostgreSQL späicheren an d'Geschwindegkeet vun der Aarbecht mat der Datebank war eis wichteg, also hu mir ugefaang PostgreSQL um Applikatiounsniveau ze sharden. De Schema uewen beschriwwen ass relativ praktesch fir dëst: wann Dir en neie PostgreSQL Shard bäidréit, ass et genuch fir d'PgBouncer Konfiguratioun ze aktualiséieren an d'Applikatioun kann direkt mat dem neie Shard schaffen.
PgBouncer Feeler Toleranz
Dëse Schema huet geschafft bis déi eenzeg PgBouncer Instanz gestuerwen ass. Mir sinn an AWS, wou all Instanzen op Hardware lancéiert ginn, déi periodesch stierft. An esou Fäll plënnert d'Instanz einfach op nei Hardware a funktionnéiert erëm. Dëst ass geschitt mat PgBouncer, awer et gouf net verfügbar. D'Resultat vun dësem Crash war datt eise Service fir 25 Minutten net verfügbar war. Fir esou Situatiounen recommandéiert AWS Redundanz op der Benotzersäit ze benotzen, déi mir zu där Zäit net ëmgesat hunn.
Duerno hu mir eescht iwwer d'Feeltoleranz vu PgBouncer a PostgreSQL Stärekéip geduecht, well eng ähnlech Situatioun mat all Instanz an eisem AWS Kont erëm ka geschéien.
Mir hunn de PgBouncer Feeler Toleranz Schema wéi follegt gebaut: all Applikatiounsserveren Zougang zum Network Load Balancer, hannert deem et zwee PgBouncers sinn. Jidderee vun de PgBouncers kuckt deeselwechte Master PostgreSQL vun all Shard. Wann d'Situatioun mat engem AWS Instanz Crash widderhëlt, gëtt all Traffic duerch en anere PgBouncer ëmgeleet. Network Load Balancer Feeler Toleranz gëtt vun AWS geliwwert.
Dëse Schema erlaabt Iech einfach nei PgBouncer Serveren ze addéieren.
Erstellt e PostgreSQL Failover Cluster
Wann Dir dëse Problem léisen, hu mir verschidden Optiounen ugesinn: selbstgeschriwwene Failover, repmgr, AWS RDS, Patroni.
Self-schrëftlech Scripten
Si kënnen d'Aarbecht vum Meeschter iwwerwaachen an, wann et net geet, d'Replique zum Master förderen an d'PgBouncer Konfiguratioun aktualiséieren.
D'Virdeeler vun dëser Approche sinn maximal Einfachheet, well Dir schreift d'Skripte selwer a versteet genau wéi se funktionnéieren.
Muecht:
- De Meeschter ass vläicht net gestuerwen; amplaz kéint et e Netzfehler ginn. Failover, net bewosst vun dësem, wäert d'Replique zum Meeschter förderen, an den ale Meeschter wäert weider schaffen. Als Resultat wäerte mir zwee Server an der Meeschterroll kréien a wësse net wéi eng vun hinnen déi lescht aktuell Donnéeën huet. Dës Situatioun gëtt och Split-Gehir genannt;
- Mir waren ouni Äntwert lénks. An eiser Konfiguratioun gëtt et e Meeschter an eng Replica, nom Wiessel gëtt d'Replika op de Master gefördert a mir hunn net méi Repliken, also musse mir eng nei Replik manuell derbäisetzen;
- Mir brauchen zousätzlech Iwwerwaachung vun der Failoveroperatioun, a mir hunn 12 PostgreSQL-Shards, dat heescht datt mir 12 Cluster mussen iwwerwaachen. Wann Dir d'Zuel vun de Shards erhéicht, musst Dir och drun erënneren de Failover ze aktualiséieren.
E selbstgeschriwwene Failover gesäit ganz komplizéiert aus a erfuerdert net-trivial Ënnerstëtzung. Mat engem PostgreSQL Stärekoup ass dëst déi einfachst Optioun, awer et skaléiert net, also ass et net gëeegent fir eis.
Repmgr
Replikatiounsmanager fir PostgreSQL Cluster, déi d'Operatioun vun engem PostgreSQL Cluster verwalten. Zur selwechter Zäit huet et keen automatesche Failover aus der Këscht, also fir ze schaffen musst Dir Ären eegene "Wrapper" uewen op der fäerdeger Léisung schreiwen. Also alles kann nach méi komplizéiert ginn wéi mat selbstgeschriwwene Scripten, dofir hu mir Repmgr net mol probéiert.
AWS RDS
Et ënnerstëtzt alles wat mir brauchen, kann Backups maachen an ënnerstëtzt e Pool vu Verbindungen. Et huet automatesch Schalter: wann de Meeschter stierft, gëtt d'Replika den neie Meeschter, an AWS ännert den DNS-Rekord op den neie Master, während d'Repliken a verschiddene AZs lokaliséiert kënne ginn.
D'Nodeeler enthalen de Mangel u feinen Astellungen. Als Beispill vu Feintuning: eis Instanzen hunn Restriktiounen fir tcp Verbindungen, déi leider net an RDS gemaach kënne ginn:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
Zousätzlech ass AWS RDS bal duebel sou deier wéi de reguläre Instanzpräis, wat den Haaptgrond war fir dës Léisung opzeginn.
Patroni
Dëst ass eng Python Schabloun fir PostgreSQL mat gudder Dokumentatioun, automateschen Failover a Quellcode op Github ze managen.
Virdeeler vum Patroni:
- All Konfiguratiounsparameter gëtt beschriwwen, et ass kloer wéi et funktionnéiert;
- Automatesch Failover funktionnéiert aus der Këscht;
- Am Python geschriwwen, a well mir selwer vill am Python schreiwen, ass et méi einfach fir eis mat Probleemer ze këmmeren a vläicht souguer d'Entwécklung vum Projet ze hëllefen;
- Ganz kontrolléiert PostgreSQL, erlaabt Iech d'Konfiguratioun op all Wirbelen vum Stärekoup op eemol z'änneren, a wann d'Applikatioun vun der neier Konfiguratioun e Restart vum Stärekoup erfuerdert, kann dëst erëm mat Patroni gemaach ginn.
Muecht:
- Et ass net kloer aus der Dokumentatioun wéi Dir richteg mat PgBouncer funktionnéiert. Obwuel et schwéier ass dëst e Minus ze nennen, well dem Patroni seng Aufgab ass PostgreSQL ze verwalten, a wéi d'Verbindunge mat Patroni funktionnéieren ass schonn eise Problem;
- Et gi wéineg Beispiller vu Patroni Implementatioun op grousse Skala, wärend et vill Beispiller vun Implementatioun vun Null gëtt.
Als Resultat hu mir Patroni gewielt fir e Failover-Cluster ze kreéieren.
Patroni Ëmsetzung Prozess
Virun Patroni hate mir 12 PostgreSQL-Schärften an enger Master- an enger Replikkonfiguratioun mat asynchroner Replikatioun. D'Applikatiounsserver hunn Zougang zu den Datenbanken duerch en Network Load Balancer, hannert deem et zwee Instanzen mat PgBouncer waren, an hannert hinnen waren all d'PostgreSQL Serveren.
Fir Patroni ëmzesetzen, musse mir eng verdeelt Cluster Konfiguratiounsspeicher auswielen. Patroni schafft mat verdeelt Konfiguratioun Stockage Systemer wéi etcd, Zookeeper, Consul. Mir hunn e vollwäertege Consul-Cluster an der Produktioun, déi a Verbindung mat Vault funktionnéiert a mir benotzen et net méi. E super Grond fir de Consul fir säin Zweck ze benotzen.
Wéi Patroni schafft mat Consul
Mir hunn e Consul-Cluster, deen aus dräi Wirbelen besteet, an e Patroni-Cluster, deen aus engem Leader an enger Replik besteet (am Patroni gëtt de Meeschter de Cluster Leader genannt, an d'Sklave ginn Repliken genannt). All Patroni Stärekoup Instanz schéckt permanent Informatiounen iwwert den Zoustand vun der Cluster zu Consul. Dofir, vum Consul kënnt Dir ëmmer déi aktuell Konfiguratioun vum Patroni-Cluster erausfannen a wien de Leader am Moment ass.
Fir Patroni mam Consul ze verbannen, studéiert just déi offiziell Dokumentatioun, déi seet datt Dir den Host an http oder https Format spezifizéiere musst, ofhängeg wéi mir mam Consul schaffen, an de Verbindungsdiagramm, optional:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpEt gesäit einfach aus, awer dëst ass wou d'Fallen ufänken. Mam Consul schaffen mir iwwer eng sécher Verbindung iwwer https an eis Verbindungskonfiguratioun wäert esou ausgesinn:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Awer esou funktionnéiert et net. Beim Startup kann de Patroni net mam Consul konnektéieren well et nach ëmmer probéiert iwwer http ze goen.
De Patroni Quellcode huet gehollef de Problem ze léisen. Et ass gutt datt et am Python geschriwwen ass. Et stellt sech eraus datt de Hostparameter net op iergendeng Manéier parséiert gëtt, an de Protokoll muss am Schema spezifizéiert ginn. Dëst ass wéi en Aarbechtskonfiguratiounsblock fir mam Consul ze schaffen fir eis ausgesäit:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Consul-Schabloun
Also hu mir d'Konfiguratiounsspeicher gewielt. Elo musse mir verstoen wéi PgBouncer seng Konfiguratioun wiesselt wann de Leader am Patroni-Cluster ännert. Et gëtt keng Äntwert op dës Fro an der Dokumentatioun, well ... Am Prinzip ass d'Aarbecht mat PgBouncer net do beschriwwen.
Op der Sich no enger Léisung hu mir en Artikel fonnt (leider, ech erënnere mech net un den Numm), wou et geschriwwe gouf datt de Consul-Schabloun ganz hëllefräich war fir PgBouncer a Patroni ze kombinéieren. Dëst huet eis opgefuerdert d'Aarbecht vum Consul-Schabloun ze studéieren.
Et huet sech erausgestallt datt Consul-Schabloun stänneg d'Konfiguratioun vum PostgreSQL-Cluster am Consul iwwerwaacht. Wann de Leader ännert, aktualiséiert et d'PgBouncer Konfiguratioun a schéckt e Kommando fir se nei ze lueden.
De grousse Virdeel vun der Schabloun ass datt et als Code gespäichert ass, also wann Dir en neie Shard bäidréit, ass et genuch fir en neien Engagement ze maachen an d'Schabloun automatesch ze aktualiséieren, den Infrastruktur als Code Prinzip z'ënnerstëtzen.
Nei Architektur mam Patroni
Als Resultat hu mir de folgende Schema vun der Aarbecht kritt:
All Applikatiounsserver kommen op de Balancer → hannendrun ginn et zwou Instanzen vu PgBouncer → op all Instanz leeft eng Consul-Schabloun, déi den Zoustand vun all Patroni-Cluster iwwerwaacht an d'Relevanz vun der PgBouncer-Konfiguratioun iwwerwaacht, déi Ufroen un den aktuelle Leader riicht. vun all Cluster.
Manuell Tester
Ier Dir et an d'Produktioun lancéiert, hu mir dëse Schema op engem klenge Testëmfeld lancéiert an d'Operatioun vum automatesche Schalter gepréift. Si hunn d'Brett opgemaach, de Sticker geréckelt an dee Moment de Leader vum Cluster "gekillt". An AWS, alles wat Dir maache musst ass d'Instanz iwwer d'Konsol auszeschalten.
De Sticker ass bannent 10-20 Sekonnen zréckkomm, an huet dunn erëm normal ugefaang ze beweegen. Dëst bedeit datt de Patroni-Cluster richteg funktionnéiert: et huet de Leader geännert, Informatioun un de Consul geschéckt, an de Consul-Schabloun huet dës Informatioun direkt opgeholl, d'PgBouncer Konfiguratioun ersat an e Kommando geschéckt fir nei ze lueden.
Wéi iwwerliewe mir ënner héijer Belaaschtung a behalen e minimale Downtime?
Alles funktionnéiert perfekt! Awer nei Froen stellen sech: Wéi funktionnéiert et ënner héijer Belaaschtung? Wéi séier a sécher alles an der Produktioun ausrollen?
D'Testëmfeld op deem mir Laaschtestung maachen hëlleft eis déi éischt Fro ze beäntweren. Et ass komplett identesch mat der Produktioun an der Architektur an huet Testdaten generéiert, déi am Volume ongeféier d'selwecht sinn wéi d'Produktioun. Mir entscheeden just ee vun de PostgreSQL Masters während dem Test ze "killen" a kucken wat geschitt. Awer virdru ass et wichteg fir d'automatesch Rollout z'iwwerpréiwen, well an dësem Ëmfeld hu mir e puer PostgreSQL Shards, sou datt mir exzellent Tester vu Konfiguratiounsskripte virun der Produktioun kréien.
Béid Aufgabe kucken ambitiéis aus, awer mir hunn PostgreSQL 9.6. Vläicht kënne mir direkt op 11.2 aktualiséieren?
Mir entscheeden dëst an 2 Etappen ze maachen: éischt d'Versioun op 11.2 aktualiséieren, dann Patroni starten.
PostgreSQL Update
Fir d'PostgreSQL Versioun séier ze aktualiséieren, musst Dir d'Optioun benotzen -k, an deem en Hard Link op der Disk erstallt gëtt an et ass net néideg Är Donnéeën ze kopéieren. Op Datenbanken vun 300-400 GB dauert den Update 1 Sekonn.
Mir hu vill Schnëtt, sou datt den Update automatesch muss gemaach ginn. Fir dëst ze maachen, hu mir en Ansible Spillbuch geschriwwen dat de ganzen Updateprozess fir eis ausféiert:
/usr/lib/postgresql/11/bin/pg_upgrade
<b>--link </b>
--old-datadir='' --new-datadir=''
--old-bindir='' --new-bindir=''
--old-options=' -c config_file='
--new-options=' -c config_file='Et ass wichteg hei ze notéieren datt ier Dir den Upgrade ufänkt, musst Dir et mam Parameter ausféieren --checkfir sécher ze sinn datt den Upgrade méiglech ass. Eist Skript ersetzt och Konfiguratiounen wärend dem Upgrade. Eist Skript ass an 30 Sekonnen ofgeschloss, wat en exzellent Resultat ass.
Lancéiere vun Patroni
Fir den zweete Problem ze léisen, kuckt just d'Patroni Konfiguratioun. Den offiziellen Repository huet eng Beispillkonfiguratioun mat initdb, déi verantwortlech ass fir eng nei Datebank ze initialiséieren wann Patroni fir d'éischt lancéiert gëtt. Awer well mir schonn eng fäerdeg Datebank hunn, hu mir dës Sektioun einfach aus der Konfiguratioun geläscht.
Wéi mir ugefaang hunn Patroni op engem fäerdege PostgreSQL-Cluster z'installéieren an ze lancéieren, hu mir en neie Problem begéint: béid Server goufen als Leader gestart. Patroni weess näischt iwwer de fréien Zoustand vum Stärekoup a probéiert béid Serveren als zwee separat Cluster mam selwechten Numm ze lafen. Fir dëse Problem ze léisen, musst Dir den Dateverzeichnis um Sklave läschen:
rm -rf /var/lib/postgresql/Dëst muss nëmmen op de Sklave gemaach ginn!
Wann Dir eng propper Replik verbënnt, mécht de Patroni e Basebackup Leader a restauréiert se an d'Replique, an hëlt dann den aktuellen Zoustand mat de Wal Logbicher op.
Eng aner Schwieregkeet déi mir begéint hunn ass datt all PostgreSQL Cluster als Standard Main genannt ginn. Wann all Stärekoup näischt iwwer deen aneren weess, ass dat normal. Awer wann Dir Patroni benotze wëllt, mussen all Cluster en eenzegaartegen Numm hunn. D'Léisung ass de Clusternumm an der PostgreSQL Konfiguratioun z'änneren.
Laascht Test
Mir hunn en Test lancéiert deen simuléiert wéi d'Benotzer op Brieder schaffen. Wann d'Laascht eisen alldeeglechen Duerchschnëtt erreecht hunn, hu mir dee selwechten Test widderholl, mir hunn eng Instanz mam Leader PostgreSQL ausgeschalt. Den automateschen Failover huet geschafft wéi mir erwaart hunn: Patroni huet de Leader geännert, Consul-Schabloun huet d'PgBouncer Konfiguratioun aktualiséiert an e Kommando geschéckt fir nei ze lueden. Laut eise Grafiken zu Grafana war et kloer datt et Verspéidungen vun 20-30 Sekonnen an e klenge Betrag vu Feeler vun de Serveren am Zesummenhang mat der Verbindung mat der Datebank waren. Dëst ass eng normal Situatioun, sou Wäerter sinn akzeptabel fir eis Failover a si definitiv besser wéi Service Downtime.
Lancéiere vun Patroni an Produktioun
Als Resultat hu mir de folgende Plang erstallt:
- Deploy Consul-Schabloun op de PgBouncer Server a starten;
- PostgreSQL Aktualiséierungen op Versioun 11.2;
- Den Numm vum Cluster änneren;
- Start vum Patroni-Cluster.
Zur selwechter Zäit erlaabt eise Schema eis den éischte Punkt bal zu all Moment ze maachen; mir kënnen all PgBouncer vun der Aarbecht een nom aneren ewechhuelen an d'Deployment an d'Start vun der Konsul-Schabloun op et maachen. Dat ass wat mir gemaach hunn.
Fir séier Testen hu mir Ansible benotzt, well mir de ganze Spillbuch schonn op engem Testëmfeld getest hunn, an d'Ausféierungszäit fir de komplette Skript war vun 1,5 bis 2 Minutte fir all Shard. Mir kënnen alles een nom aneren op all Shard ausrollen ouni eise Service ze stoppen, awer mir missten all PostgreSQL fir e puer Minutten ausschalten. An dësem Fall kënnen d'Benotzer deenen hir Donnéeën op dësem Schnëtt sinn net fäeg sinn de Moment voll ze schaffen, an dat ass fir eis inakzeptabel.
De Wee aus dëser Situatioun war de geplangten Ënnerhalt, dee mir all 3 Méint maachen. Dëst ass eng Fënster fir geplangten Aarbecht, wa mir eise Service komplett ausschalten an d'Datebankinstanzen aktualiséieren. Et war nach eng Woch bis déi nächst Fënster, a mir hu beschloss just ze waarden a weider ze preparéieren. Wärend der Waarde hu mir eis Spillwette zousätzlech gehackt: fir all PostgreSQL-Shard hu mir eng Ersatz-Replika am Fall vun engem Echec opgeholl, fir déi lescht Donnéeën ze späicheren, an eng nei Instanz fir all Shard bäigefüügt, déi eng nei Replica am Patroni soll ginn Cluster, fir net e Kommando auszeginn fir Daten ze läschen. All dëst huet gehollef de Risiko vu Feeler ze minimiséieren.
Mir hunn eise Service nei gestart, alles funktionnéiert wéi et sollt, d'Benotzer hunn weider geschafft, awer op de Grafike hu mir eng anormal héich Belaaschtung op de Consul-Server gemierkt.
Firwat hu mir dat net am Testëmfeld gesinn? Dëse Problem illustréiert ganz gutt datt et néideg ass den Infrastruktur als Code Prinzip ze verfollegen an déi ganz Infrastruktur ze verbesseren, vun Testëmfeld bis zur Produktioun. Soss ass et ganz einfach de Problem ze kréien dee mir hunn. Wat ass geschitt? Consul ass fir d'éischt an der Produktioun opgetaucht, an dann an Testëmfeld; als Resultat, an Testëmfeld war d'Versioun vum Consul méi héich wéi an der Produktioun. Just an enger vun de Verëffentlechunge gouf e CPU Leck wann Dir mat Konsul-Schabloun geschafft hutt geléist. Also hu mir de Consul einfach aktualiséiert, sou de Problem geléist.
Restart Patroni Stärekoup
Mir kruten awer en neie Problem, dee mir net emol verdächtegt hunn. Wann Dir de Consul aktualiséiert, hu mir einfach de Consul Node aus dem Stärekoup mam Konsul verlooss Kommando → Patroni verbënnt mat engem anere Consul Server → alles funktionnéiert. Awer wa mir op déi lescht Instanz vum Consul Cluster ukomm sinn an et de Konsul verlooss Kommando geschéckt hunn, sinn all Patroni Cluster einfach nei gestart, an an de Logbicher hu mir de folgende Feeler gesinn:
ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>De Patroni-Cluster konnt net Informatiounen iwwer säi Cluster kréien an huet nei gestart.
Fir eng Léisung ze fannen, hu mir d'Autoren vu Patroni iwwer en Thema op github kontaktéiert. Si hu Verbesserunge fir eis Konfiguratiounsdateien virgeschloen:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Mir konnten d'Thema an engem Testëmfeld replizéieren an dës Astellungen do testen, awer leider hunn se net geschafft.
De Problem bleift nach ëmmer ongeléist. Mir plangen déi folgend Léisungen ze probéieren:
- Benotzt Consul-Agent op all Instanz vum Patroni-Cluster;
- Fix de Problem am Code.
Mir verstinn wou de Feeler opgetrueden ass: wahrscheinlech ass de Problem am Gebrauch vum Standard Timeout, deen net duerch d'Konfiguratiounsdatei iwwerschriwwe gëtt. Wann de leschte Consul-Server aus dem Cluster geläscht gëtt, freet de ganze Consul-Cluster, wat méi laang dauert wéi eng Sekonn; Dofir kann de Patroni den Zoustand vum Cluster net kréien an de ganze Cluster komplett nei starten.
Glécklecherweis hu mir keng Feeler méi begéint.
Resultater vun benotzen Patroni
Nom erfollegräiche Start vu Patroni hu mir eng zousätzlech Replika an all Cluster bäigefüügt. Elo huet all Cluster e Quorum: ee Leader an zwee Repliken, fir géint Split-Gehir beim Wiessel ze schützen.
Patroni schafft fir méi wéi dräi Méint an der Produktioun. Während dëser Zäit huet hien et scho fäerdeg bruecht eis ze hëllefen. Viru kuerzem ass de Leader vun engem vun de Cluster am AWS gestuerwen, den automatesche Failover huet geschafft an d'Benotzer hunn weider geschafft. Patroni huet seng Haaptaufgab erfëllt.
E kuerze Resumé vum Patroni ze benotzen:
- Einfachheet vun Configuratioun Ännerungen. Et ass genuch d'Konfiguratioun op enger Instanz z'änneren an et gëlt fir de ganze Cluster. Wann e Restart erfuerderlech ass fir déi nei Konfiguratioun z'applizéieren, wäert Patroni Iech doriwwer informéieren. Patroni kann de ganze Cluster mat engem Kommando nei starten, wat och ganz bequem ass.
- Den automatesche Failover funktionnéiert an huet eis scho gehollef.
- PostgreSQL aktualiséieren ouni Applikatioun Downtime. Dir musst éischt d'Repliken op déi nei Versioun aktualiséieren, dann de Leader am Patroni-Cluster änneren an den alen Leader aktualiséieren. An dësem Fall geschitt déi néideg Tester vun automateschen Failover.
Source: will.com