Aféierung

Virun enger Zäit krut ech d'Aufgab fir e Failover-Cluster z'entwéckelen fir PostgreSQL, operéiert a verschiddenen Datenzenteren, déi duerch optesch Glasfaser an enger Stad verbonne sinn, a fäeg sinn e Feeler (zum Beispill Blackout) vun engem Datenzenter ze widderstoen. Als Software déi fir Feeler Toleranz verantwortlech ass, hunn ech gewielt pacemakerwell dëst déi offiziell Léisung vu RedHat ass fir Failover Cluster ze kreéieren. Et ass gutt well RedHat Ënnerstëtzung dofir gëtt, a well dës Léisung universell ass (modulär). Mat senger Hëllef wäert et méiglech sinn Fehltoleranz net nëmme vu PostgreSQL ze garantéieren, awer och vun anere Servicer, entweder mat Standardmoduler oder erstellt se fir spezifesch Besoinen.

Dës Entscheedung huet eng raisonnabel Fro opgeworf: wéi Feelertolerant wäert e Failover-Cluster sinn? Fir dëst z'ënnersichen, hunn ech eng Testbank entwéckelt, déi verschidde Feeler op de Clusternoden simuléiert, waart op de Service fir restauréiert ze ginn, de gescheiterten Node erëmfënnt a weider an enger Loop testen. Dëse Projet gouf ursprénglech hapgsql genannt, awer mat der Zäit hunn ech mech mam Numm langweilen, deen nëmmen ee Vokal hat. Dofir hunn ech ugefaang Feeler-tolerant Datenbanken ze nennen (a schwiewen IP déi op se weist) krogan (e Charakter aus engem Computerspill an deem all wichteg Organer duplizéiert sinn), an Noden, Cluster an de Projet selwer sinn tuchanka (de Planéit wou d'Krogans liewen).

Elo huet d'Gestioun erlaabt oppen de Projet un der Open Source Gemeinschaft ënner der MIT Lizenz. D'README wäert geschwënn op Englesch iwwersat ginn (well et gëtt erwaart datt d'Haaptkonsumenten Pacemaker a PostgreSQL Entwéckler sinn), an ech hunn decidéiert déi al russesch Versioun vum README (deelweis) a Form vun dësem Artikel ze presentéieren.

Cluster ginn op virtuelle Maschinnen ofgesat VirtualBox. Insgesamt 12 virtuelle Maschinnen (36GiB am Ganzen) wäerten ofgesat ginn, déi 4 Feeler-tolerant Cluster bilden (verschidden Optiounen). Déi éischt zwee Cluster besteet aus zwee PostgreSQL Serveren, déi a verschiddenen Datenzenteren lokaliséiert sinn, an engem gemeinsame Server Zeien c quorum Apparat (gehost op enger bëlleger virtueller Maschinn an engem drëtten Rechenzentrum), wat d'Onsécherheet léist 50% / 50%, gitt Är Stëmm un enger vun de Parteien. Drëtte Stärekoup an dräi Rechenzentren: ee Master, zwee Sklaven, nee quorum Apparat. De véierte Stärekoup besteet aus véier PostgreSQL Serveren, zwee pro Datenzenter: ee Master, de Rescht Repliken, a benotzt och Zeien c quorum Apparat. Déi véiert kann den Echec vun zwee Serveren oder engem Rechenzentrum widderstoen. Dës Léisung kann op eng méi grouss Unzuel vu Repliken skaléiert ginn, wann néideg.

Genau Zäit Service ntpd och fir Feeler Toleranz reconfigured, mee et benotzt der Method selwer ntpd (orphan Modus). Gemeinsam Server Zeien Akten als zentrale NTP Server, verdeelt seng Zäit un all Cluster, doduerch all Server mateneen synchroniséiert. Wann Zeien feelt oder gëtt isoléiert, da fänkt ee vun de Clusterserveren (am Cluster) un seng Zäit ze verdeelen. Auxiliary Caching HTTP Proxy och opgewuess zu Zeien, mat senger Hëllef, aner virtuell Maschinnen hunn Zougang zu Yum Repositories. A Wierklechkeet, Servicer wéi präzis Zäit a Proxy wäerten héchstwahrscheinlech op dedizéierten Server gehost ginn, awer am Stand gi se gehost. Zeien nëmmen d'Zuel vun virtuell Maschinnen a Plaz ze retten.

Versiounen

v0 vun. Schafft mat CentOS 7 a PostgreSQL 11 op VirtualBox 6.1.

Cluster Struktur

All Cluster sinn entwéckelt fir a verschidde Rechenzentren ze lokaliséieren, an ee flaach Netzwierk kombinéiert a musse Versoen oder Netzisolatioun vun engem eenzegen Rechenzentrum widderstoen. Dat ass wouvir ass net méiglech benotzen fir Schutz géint gespléckt-Gehir Standard Pacemaker Technologie genannt STONITH (Schéisst den anere Node Am Kapp) oder Fong. Seng Essenz: wann d'Noden am Stärekoup ufänken ze verdächtegen datt eppes mat engem Node falsch ass, et net reagéiert oder sech falsch behuelen, da schalten se se gezwongen aus duerch "extern" Apparater, zum Beispill eng IPMI oder UPS Kontrollkaart . Awer dëst funktionnéiert nëmmen a Fäll wou, am Fall vun engem eenzegen Ausfall, den IPMI oder den UPS Server weider funktionnéiert. Hei plangen mir géint eng vill méi katastrophal Echec ze schützen, wann de ganzen Daten Zentrum versoen (zum Beispill, verléiert Muecht). A mat esou engem Refus, alles stonith-Apparater (IPMI, UPS, etc.) wäert och net schaffen.

Amplaz baséiert de System op der Iddi vum Quorum. All Wirbelen hunn eng Stëmm, an nëmmen déi, déi méi wéi d'Halschent vun all Wirbelen gesinn, kënne schaffen. Dës Quantitéit vun "Halschent + 1" gëtt genannt Quorum. Wann de Quorum net erreecht gëtt, da entscheet den Node datt et an der Netzisolatioun ass a muss seng Ressourcen ausschalten, d.h. dat ass wat et ass Split-Gehir Schutz. Wann d'Software, déi fir dëst Verhalen verantwortlech ass, net funktionnéiert, da muss e Waachhond, zum Beispill, baséiert op IPMI, schaffen.

Wann d'Zuel vun den Noden gläich ass (e Stärekoup an zwee Rechenzentren), da kann sougenannt Onsécherheet entstoen 50% / 50% (fofzeg-fofzeg) wann d'Netz Isolatioun de Stärekoup genee an der Halschent deelt. Dofir, fir eng souguer Zuel vu Wirbelen, addéiere mer quorum Apparat ass en ongewollten Daemon deen op der bëllegst virtueller Maschinn an engem drëtten Rechenzentrum lancéiert ka ginn. Hie gëtt säi Vote un ee vun de Segmenter (déi hie gesäit), an domat léist d'50% / 50% Onsécherheet. Ech hunn de Server genannt op deem de Quorum-Apparat lancéiert gëtt Zeien (Terminologie vum repmgr, mir hunn et gär).

Ressourcen kënne vu Plaz op Plaz geréckelt ginn, zum Beispill, vu falschen Serveren op gesond, oder um Kommando vu Systemadministratoren. Also datt Cliente wësse wou d'Ressourcen déi se brauchen sinn lokaliséiert (wou ze verbannen?), schwiewend IP (schwammen IP). Dëst sinn IPs déi Pacemaker ronderëm Noden réckelen (alles ass op engem flaach Netzwierk). Jidderee vun hinnen symboliséiert eng Ressource (Service) a wäert lokaliséiert sinn wou Dir musst konnektéieren fir Zougang zu dësem Service ze kréien (an eisem Fall eng Datebank).

Tuchanka1 (Circuit mat Verdichtung)

Struktur

D'Iddi war datt mir vill kleng Datenbanken mat niddereger Belaaschtung hunn, fir déi et onprofitabel ass en engagéierten Sklave-Server am waarme Standby-Modus ze halen fir nëmmen Transaktiounen ze liesen (et ass kee Besoin fir sou eng Verschwendung vu Ressourcen).

All Datenzenter huet ee Server. All Server huet zwee PostgreSQL Instanzen (an der PostgreSQL Terminologie gi se Cluster genannt, awer fir Duercherneen ze vermeiden wäert ech se Instanzen nennen (no Analogie mat aneren Datenbanken), an ech wäert nëmmen Pacemaker Cluster Cluster nennen). Eng Instanz funktionnéiert am Mastermodus, an nëmmen et bitt Servicer (nëmme Float IP féiert dozou). Déi zweet Instanz funktionéiert als Sklave fir den zweeten Rechenzentrum, a liwwert Servicer nëmme wa säi Meeschter feelt. Well déi meescht vun der Zäit nëmmen eng Instanz vun zwee (de Master) Servicer ubitt (Ufroen ausféieren), sinn all Serverressourcen fir de Master optimiséiert (Erënnerung gëtt fir de shared_buffers Cache zougewisen, etc.), awer sou datt déi zweet Instanz huet och genuch Ressourcen (awer fir suboptimal Operatioun duerch de Dateiesystem-Cache) am Fall vun engem Echec vun engem vun den Datenzenteren. De Sklave gëtt keng Servicer (mécht net nëmmen Ufroen) während normal Operatioun vum Stärekoup, sou datt et kee Krich fir Ressourcen mam Meeschter op der selwechter Maschinn gëtt.

Am Fall vun zwee Wirbelen ass Feeler Toleranz nëmme méiglech mat asynchroner Replikatioun, well mat synchroner Replikatioun de Versoen vun engem Sklave féiert zum Stop vum Master.

Echec Zeien

Echec Zeien (quorum Apparat) Ech wäert nëmme fir den Tuchanka1 Stärekoup berücksichtegen, mat all deenen aneren wäert et déiselwecht Geschicht sinn. Wann Zeien feelt, ännert sech näischt an der Stärekoupstruktur, alles funktionnéiert weider op déiselwecht Manéier wéi et gemaach huet. Awer de Quorum wäert 2 vun 3 ginn, an dofir wäert all spéider Echec fatal fir de Cluster sinn. Et muss nach dringend gefléckt ginn.

Tuchanka1 Refus

Ausgefall vun engem vun den Rechenzentren fir Tuchanka1. An dësem Fall Zeien stellt säi Vote op en zweeten Node an engem zweeten Rechenzentrum. Do gëtt de fréiere Sklave zu engem Meeschter, als Resultat, béid Masters schaffen um selwechte Server a béid hir Float IPs weisen op si.

Tuchanka 2 (klassesch)

Struktur

Klassesch Schema vun zwee Wirbelen. De Meeschter schafft un engem, de Sklave op der zweeter. Béid kënnen Ufroen ausféieren (de Sklave gëtt nëmme gelies), sou datt béid duerch Float IP ugewise ginn: krogan2 ass de Master, krogan2s1 ass de Sklave. Souwuel de Meeschter wéi och de Sklave wäerte Feelertoleranz hunn.

Am Fall vun zwee Wirbelen ass Feeler Toleranz nëmme méiglech mat asynchroner Replikatioun, well mat synchroner Replikatioun wäert de Versoen vum Sklave zum Stop vum Master féieren.

Tuchanka2 Refus

Wann ee vun de Rechenzentren klappt Zeien Stëmmen fir déi zweet. Am eenzegen funktionnéierende Rechenzentrum gëtt de Master opgehuewen, a béid Schwämm IPs weisen drop hin: de Master an de Sklave. Natierlech muss d'Instanz esou konfiguréiert sinn datt et genuch Ressourcen huet (Verbindungsgrenzen, etc.) fir gläichzäiteg all Verbindungen an Ufroe vum Master a Sklave Float IP ze akzeptéieren. Dat ass, während normal Operatioun soll et eng genuch Versuergung vu Grenzen hunn.

Tuchanka4 (vill Sklaven)

Struktur

Schon en aneren Extrem. Et gi Datenbanken déi vill Lies-nëmmen Ufroe kréien (en typesche Fall vun engem héichlaaschte Site). Tuchanka4 ass eng Situatioun wou et dräi oder méi Sklaven ka sinn fir sou Ufroen ze behandelen, awer nach ëmmer net ze vill. Mat enger ganz grousser Zuel vu Sklaven wäert et néideg sinn en hierarchesche Replikatiounssystem ze erfannen. Am Minimum Fall (am Bild), all eenzel vun den zwee Daten Zentren huet zwee Serveren, all mat enger PostgreSQL Instanz.

Eng aner Feature vun dësem Schema ass datt et scho méiglech ass eng synchron Replikatioun ze organiséieren. Et ass konfiguréiert fir ze replizéieren, wa méiglech, an en aneren Datenzenter, anstatt op eng Replik am selwechte Rechenzentrum wéi de Master. De Meeschter an all Sklave ginn op eng Schwämm IP ugewisen. Glécklech, tëscht Sklaven wäert et néideg sinn Ufroen iergendwéi ze balanséieren sql Proxy, zum Beispill, op der Client Säit. Verschidden Zorte vu Clienten kënnen verschidden Zorte verlaangen sql Proxy, an nëmmen Client Entwéckler wëssen, wien brauch déi. Dës Funktionalitéit kann entweder vun engem externen Daemon oder vun enger Clientbibliothéik (Verbindungspool), etc. All dëst geet iwwer d'Thema vun engem Failover Datebankcluster (Failover SQL Proxy kann onofhängeg ëmgesat ginn, zesumme mat Client Feeler Toleranz).

Tuchanka4 Refus

Wann een Datenzenter (dh zwee Serveren) feelt, stëmmt Zeien fir den zweeten. Als Resultat ginn et zwee Serveren déi am zweeten Datenzenter lafen: ee leeft e Master, an de Master Float IP weist drop hin (fir Lies-Schreif-Ufroen ze kréien); an op den zweeten Server gëtt et e Sklave deen mat synchroner Replikatioun leeft, an ee vun de Sklave Float IPs weist drop hin (fir nëmme liesen Ufroen).

Déi éischt Saach ze bemierken ass datt net all Sklave Float IPs Aarbechter sinn, awer nëmmen een. A fir mat et richteg ze schaffen, wäert et néideg sinn sql Proxy all Ufroen op déi eenzeg verbleiwen Float IP ëmgeleet; a wann sql Proxy nee, da kënnt Dir all Float IP Sklaven opzielen, getrennt duerch Komma an der Verbindungs-URL. An dësem Fall, mat libpq d'Verbindung wäert op déi éischt funktionéierend IP sinn, dëst gëtt am automateschen Testsystem gemaach. Vläicht an anere Bibliothéiken, zum Beispill, JDBC, dëst funktionnéiert net an ass néideg sql Proxy. Dëst gëtt gemaach well Float IPs fir Sklaven verbueden si gläichzäiteg op engem Server opgeworf ze ginn, sou datt se gläichméisseg tëscht Sklave Serveren verdeelt ginn wann et e puer vun hinnen lafen.

Zweetens: och am Fall vun engem Datenzenterfehler gëtt d'synchron Replikatioun erhale gelooss. An och wann e sekundäre Feeler geschitt, dat heescht, ee vun den zwee Serveren am reschtlechen Rechenzentrum fällt aus, de Stärekoup, och wann et ophält Servicer ze liwweren, behält nach ëmmer Informatioun iwwer all engagéiert Transaktiounen, fir déi hien d'Bestätegung vum Engagement gemaach huet. (et gëtt keng Verloschtinformatioun am Fall vum sekundären Echec).

Tuchanka3 (3 Rechenzentren)

Struktur

Dëst ass e Stärekoup fir eng Situatioun wou et dräi voll funktionéierend Datenzenteren sinn, déi all e voll funktionéierend Datebankserver hunn. An dësem Fall quorum Apparat net néideg. Een Datenzenter gëtt vun engem Meeschter besat, déi aner zwee si vu Sklaven. Replikatioun ass synchron, Typ ANY (Slave1, Slave2), dat heescht, de Client kritt eng Verpflichtungsbestätegung wann ee vun de Sklaven déi éischt ass fir ze reagéieren datt hien den Engagement ugeholl huet. Ressourcen ginn ugewisen vun engem Float IP fir de Master an zwee fir Sklaven. Am Géigesaz zu Tuchanka4 sinn all dräi Float IPs Feelertolerant. Fir nëmmen Lies-SQL Ufroen ze balanséieren, kënnt Dir benotzen sql Proxy (mat getrennten Feeler Toleranz), oder eng Sklave Float IP un d'Halschent vun de Clienten zougewisen, an déi aner Halschent un déi zweet.

Tuchanka3 Refus

Wann ee vun den Datenzenteren klappt, bleiwen zwee. An engem ginn de Master a Float IP vum Master opgehuewen, an der zweeter - de Sklave a béid Sklave Float IPs (d'Instanz muss eng duebel Reserve vu Ressourcen hunn fir all Verbindunge vu béide Sklave Float IPs ze akzeptéieren). Synchron Replikatioun tëscht Meeschter a Sklaven. Och de Cluster späichert Informatioun iwwer engagéiert a bestätegt Transaktiounen (et gëtt keng Informatiounsverloscht) am Fall vun der Zerstéierung vun zwee Datenzenteren (wann se net gläichzäiteg zerstéiert ginn).

Ech hu beschloss net eng detailléiert Beschreiwung vun der Dateistruktur an der Deployment ze enthalen. Jiddereen dee wëll spillen, kann dat alles am README liesen. Ech bidden nëmmen eng Beschreiwung vum automatiséierten Test.

Automatesch Test System

Fir d'Feeltoleranz vu Cluster ze testen andeems verschidde Feeler simuléiert ginn, gouf en automateschen Testsystem erstallt. Gestart duerch Skript test/failure. D'Skript kann als Parameteren d'Zuel vun de Cluster huelen, déi Dir wëllt testen. Zum Beispill dëse Kommando:

test/failure 2 3

wäert nëmmen déi zweet an drëtt Stärekoup Test. Wann Parameteren net spezifizéiert sinn, da ginn all Cluster getest. All Cluster ginn parallel getest, an d'Resultat gëtt an der tmux Panel ugewisen. Tmux benotzt en dedizéierten tmux Server, sou datt de Skript ënner Standard tmux ausgefouert ka ginn, wat zu engem nestet tmux resultéiert. Ech recommandéieren den Terminal an enger grousser Fënster a mat enger klenger Schrëft ze benotzen. Ier den Test ufänkt, ginn all virtuell Maschinnen zréck op e Snapshot zur Zäit wou de Skript fäerdeg ass setup.

Den Terminal ass a Spalten opgedeelt no der Unzuel vun de Cluster déi getest ginn; Par défaut (am Screenshot) ginn et véier. Ech wäert den Inhalt vun de Sailen beschreiwen mat dem Beispill vun Tuchanka2. D'Paneele am Screenshot sinn nummeréiert:

1. Teststatistike ginn hei ugewisen. Kolonnen:
   • ze maachen - den Numm vum Test (Funktioun am Skript) deen de Feeler emuléiert.
   • Reaktioun - arithmetesch Duerchschnëttszäit a Sekonnen wärend de Stärekoup seng Funktionalitéit erëmfonnt huet. Et gëtt gemooss vum Ufank vum Skript, deen e Feeler emuléiert, bis de Moment wou de Cluster seng Funktionalitéit restauréiert a fäeg ass weider Servicer ze liwweren. Wann d'Zäit ganz kuerz ass, zum Beispill, sechs Sekonnen (dëst geschitt a Cluster mat verschiddene Sklaven (Tuchanka3 an Tuchanka4)), heescht dat, datt de Feeler um asynchrone Sklave war an d'Performance op kee Fall beaflosst; et waren keng Stärekoup Staat schalt.
   • Ofwäichung - weist d'Verbreedung (Genauegkeet) vum Wäert Reaktioun mat der Standarddeviatiounsmethod.
   • Grof - wéi oft dësen Test gemaach gouf.
2. E kuerze Log erlaabt Iech ze evaluéieren wat de Cluster am Moment mécht. D'Iteratioun (Test) Zuel, Zäitstempel an Numm vun der Operatioun ginn ugewisen. Ze laang lafen (> 5 Minutten) weist op e Problem.
3. Häerz (Häerz) - aktuell Zäit. Fir visuell Bewäertung vun der Leeschtung Meeschter Déi aktuell Zäit gëtt stänneg op säin Dësch geschriwwe mam Float IP Master. Wann et erfollegräich ass, gëtt d'Resultat an dësem Panel ugewisen.
4. schloën (Puls) - "aktuell Zäit", déi virdru vum Skript opgeholl gouf Häerz ze Meeschter, elo liesen aus Sklave iwwer säi Float IP. Erlaabt Iech visuell d'Leeschtung vum Sklave a Replikatioun ze bewäerten. An Tuchanka1 gi keng Sklaven mat Float IP (keng Sklaven déi Servicer ubidden), awer et ginn zwou Instanzen (DBs), also gëtt et net hei gewisen schloënan Häerz zweet Instanz.
5. Iwwerwaachung vun der Cluster Gesondheet mam Utility pcs mon. Weist d'Struktur, d'Verdeelung vu Ressourcen iwwer Noden an aner nëtzlech Informatioun.
6. System Iwwerwaachung vun all virtuell Maschinn am Cluster gëtt hei ugewisen. Et kënne méi esou Paneele sinn ofhängeg vun wéivill virtuelle Maschinnen de Stärekoup huet. Zwee Grafiken CPU Luet (virtuell Maschinnen hunn zwee Prozessoren), virtuell Maschinn Numm, System Lueden (genannt Load Moyenne well et duerchschnëttlech iwwer 5, 10 a 15 Minutten ass), Prozessdaten an Erënnerungsallokatioun.
7. Spuer vum Skript deen Tester mécht. Am Fall vun enger Feelfunktioun - eng plötzlech Ënnerbriechung vun der Operatioun oder engem endlosen Waardezyklus - hei kënnt Dir de Grond fir dëst Verhalen gesinn.

Tester ginn an zwou Etappen duerchgefouert. Als éischt geet de Skript duerch all Zorte vun Tester, wielt zoufälleg eng virtuell Maschinn op déi dësen Test applizéiert gëtt. Da gëtt en endlosen Zyklus vun Tester gemaach, déi virtuell Maschinnen an d'Feeler ginn all Kéier zoufälleg ausgewielt. Plötzlech Ofschloss vum Testskript (ënnen Panel) oder eng endlos Loop fir op eppes ze waarden (> 5 Minutte Ausféierungszäit fir eng Operatioun, dëst kann an der Spuer gesi ginn) weist datt e puer vun den Tester op dësem Cluster gescheitert sinn.

All Test besteet aus de folgenden Operatiounen:

1. Lancéiere eng Funktioun déi e Feeler emuléiert.
2. Fäerdeg? - waart op de Cluster fir restauréiert ze ginn (wann all Servicer geliwwert ginn).
3. Weist de Cluster Erhuelung Timeout (Reaktioun).
4. gefléckt - de Stärekoup gëtt "reparéiert." Duerno sollt et zréck an e voll funktionnellen Zoustand a prett sinn fir déi nächst Feelfunktioun.

Hei ass eng Lëscht vun Tester mat enger Beschreiwung vu wat se maachen:

• ForkBomb: Erstellt "Out of memory" mat enger Gabelbomm.
• OutOfSpace: D'Festplack ass voll. Awer den Test ass zimmlech symbolesch; mat der onbedeitender Belaaschtung déi wärend dem Test erstallt gëtt, fällt PostgreSQL normalerweis net wann d'Harddisk voll ass.
• Postgres-KILL: killt PostgreSQL mam Kommando killall -KILL postgres.
• Postgres-STOP: hänkt PostgreSQL Kommando killall -STOP postgres.
• Ausmaachen: "de-energiséiert" déi virtuell Maschinn mam Kommando VBoxManage controlvm "виртуалка" poweroff.
• zrécksetzen: iwwerlaascht déi virtuell Maschinn mam Kommando VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: suspendéiert den SBD Demon mam Kommando killall -STOP sbd.
• Zou maachen: schéckt e Kommando op déi virtuell Maschinn iwwer SSH systemctl poweroff, de System schléisst graziéis aus.
• UnLink: Reseau Isolatioun, Kommando VBoxManage controlvm "виртуалка" setlinkstate1 off.

Testen ofgeschloss entweder mam Standard tmux Kommando "kill-window" Ctrl-b &, oder de Kommando "detach-client". Ctrl-b d: Op dësem Punkt ass den Test eriwwer, tmux mécht zou, virtuell Maschinnen ginn ausgeschalt.

Problemer identifizéiert während Testen

• De Moment Watchdog Demon sbd funktionnéiert fir observéiert Daemonen ze stoppen, awer se net afréieren. An, als Resultat, Feeler déi nëmmen zu Afréiere féieren Corosync и pacemaker, awer net hänken sbd. Fir kontrolléieren Corosync hu schonn PR#83 (op GitHub um sbd), un de Fuedem ugeholl Meeschtesch. Si versprach (an PR # 83) datt et eppes ähnlechen fir Pacemaker ginn géif, Ech hoffen, datt duerch Red Hat 8 gëtt gemaach. Awer sou "Feelfunktioune" si spekulativ a kënne ganz einfach kënschtlech simuléiert ginn, z.B. killall -STOP corosync, mee treffen ni am richtege Liewen.

• У pacemaker an der Versioun fir CentOS 7 falsch gesat sync_timeout у quorum Apparat, als Resultat vun wann een Node gescheitert, mat e puer Wahrscheinlechkeet déi zweet Node och nei gestart, op déi de Meeschter soll plënneren. Heelt duerch Erweiderung sync_timeout у quorum Apparat während der Installatioun (am Skript setup/setup1). Dës Ännerung gouf net vun den Entwéckler ugeholl pacemaker, amplaz hu se versprach, d'Infrastruktur esou nei ze gestalten (op enger ongespezifizéierter Zukunft), datt dësen Timeout automatesch berechent gëtt.

• Wann d'Datebankkonfiguratioun dat spezifizéiert LC_MESSAGES (Text Messagen) Unicode ka benotzt ginn, z.B. ru_RU.UTF-8, dann beim Startup Postgruppen an engem Ëmfeld wou d'Lokalitéit net UTF-8 ass, sot an engem eidelen Ëmfeld (hei pacemaker+pgsqlms(paf) leeft Postgruppen), dann de Logbuch wäert Fro Zeechen amplaz UTF-8 Buschtawen enthalen. D'PostgreSQL Entwéckler hunn net ausgemaach iwwer wat an dësem Fall ze maachen. Et kascht, Dir musst installéieren LC_MESSAGES=en_US.UTF-8 wann Dir eng Datebankinstanz konfiguréiert (schaaft).

• Wann wal_receiver_timeout agestallt ass (par défaut ass et 60s), dann während dem PostgreSQL-STOP Test op de Master am tuchanka3 an tuchanka4 Cluster Replikatioun verbënnt net mam neie Master. Replikatioun do ass synchron, also net nëmmen de Sklave stoppt, awer och den neie Meeschter. Schafft ronderëm andeems Dir wal_receiver_timeout=0 setzt wann Dir PostgreSQL konfiguréiert.

• Heiansdo hunn ech Replikatiounsfräiheet am PostgreSQL am ForkBomb Test observéiert (Erënnerungsiwwerlaf). No ForkBomb kënnen heiansdo Sklaven net mam neie Meeschter konnektéieren. Ech hunn dat nëmmen an de tuchanka3- an tuchanka4-Cluster begéint, wou de Meeschter wéinst synchroner Replikatioun gefruer ass. De Problem ass no enger laanger Zäit (ongeféier zwou Stonnen) vu sech selwer fortgaang. Méi Fuerschung ass néideg fir dëst ze korrigéieren. D'Symptomer sinn ähnlech wéi de fréiere Käfer, deen aus engem anere Grond verursaacht gëtt, awer mat de selwechte Konsequenzen.

Krogan Bild geholl aus Deviant Art mat Erlaabnis vum Auteur:

Source: will.com