Ynlieding

In skoft lyn krige ik de taak om in failover-kluster te ûntwikkeljen foar PostgreSQL, operearje yn ferskate data sintra ferbûn troch glêstried binnen ien stêd, en by steat om te wjerstean in flater (Bygelyks, blackout) fan ien data sintrum. As de software dy't ferantwurdlik is foar fouttolerânsje, keas ik pacemakerom't dit de offisjele oplossing fan RedHat is foar it meitsjen fan failover-klusters. It is goed om't RedHat der stipe foar leveret, en om't dizze oplossing universeel is (modulêr). Mei har help sil it mooglik wêze om fouttolerânsje te garandearjen net allinich fan PostgreSQL, mar ek fan oare tsjinsten, itsij mei help fan standert modules of meitsje se foar spesifike behoeften.

Dit beslút rôp in ridlike fraach op: hoe fouttolerant sil in failoverkluster wêze? Om dit te ûndersiikjen, haw ik in testbank ûntwikkele dy't ferskate mislearrings simulearret op 'e klusterknooppunten, wachtet op tsjinst om te restaurearjen, herstelt de mislearre knooppunt en bliuwt te testen yn in lus. Dit projekt waard oarspronklik hapgsql neamd, mar yn 'e rin fan' e tiid ferfeelde ik my mei de namme, dy't mar ien fokaal hie. Dêrom begon ik fouttolerante databases te neamen (en float IP dy't nei har wiist) krogan (in karakter út in kompjûterspultsje wêryn alle wichtige organen duplikearre binne), en knopen, klusters en it projekt sels binne tuchanka (de planeet dêr't de krogans libje).

No hat de direksje tastien iepenje it projekt foar de iepen boarne-mienskip ûnder de MIT-lisinsje. De README sil ynkoarten oerset wurde yn it Ingelsk (om't it wurdt ferwachte dat de wichtichste konsuminten Pacemaker en PostgreSQL-ûntwikkelders sille wêze), en ik besleat de âlde Russyske ferzje fan 'e README (foar in part) te presintearjen yn' e foarm fan dit artikel.

Klusters wurde ynset op firtuele masines VirtualBox. In totaal fan 12 firtuele masines (36GiB yn totaal) sille wurde ynset, dy't foarmje 4 fout-tolerante klusters (ferskillende opsjes). De earste twa klusters besteane út twa PostgreSQL-tsjinners, dy't lizze yn ferskate datasintra, en in mienskiplike server tsjûge c quorum apparaat (hosted op in goedkeape firtuele masine yn in tredde datasintrum), dy't ûnwissichheid oplost 50% / 50%, jo stim jaan oan ien fan 'e partijen. Tredde kluster yn trije datasintra: ien master, twa slaven, nee quorum apparaat. It fjirde kluster bestiet út fjouwer PostgreSQL-tsjinners, twa per datasintrum: ien master, de rest replika's, en brûkt ek tsjûge c quorum apparaat. De fjirde kin it mislearjen fan twa servers of ien datasintrum ferneare. Dizze oplossing kin wurde opskaald nei in grutter oantal replika's as it nedich is.

Akkurate tiid tsjinst ntpd ek rekonfigurearre foar skuld tolerânsje, mar it brûkt de metoade sels ntpd (weesmodus). Dielde tsjinner tsjûge fungearret as in sintrale NTP tsjinner, distribúsje syn tiid oan alle klusters, dêrmei syngronisearje alle tsjinners mei elkoar. As tsjûge mislearret of wurdt isolearre, dan sil ien fan 'e klustertsjinners (binnen it kluster) begjinne om syn tiid te fersprieden. Auxiliary caching HTTP proxy ek grutbrocht ta tsjûge, mei har help hawwe oare firtuele masines tagong ta Yum-repositories. Yn 'e realiteit sille tsjinsten lykas krekte tiid en proxy's nei alle gedachten wurde hosted op tawijd servers, mar yn' e stand wurde se hosted op tsjûge allinich om it oantal firtuele masines en romte te bewarjen.

Ferzjes

v0. Wurket mei CentOS 7 en PostgreSQL 11 op VirtualBox 6.1.

Klusterstruktuer

Alle klusters binne ûntworpen om te lizzen yn meardere datasintra, kombineare yn ien flak netwurk en moatte tsjin mislearring of netwurkisolaasje fan ien datasintrum wjerstean. Dêrom is ûnmooglik brûke foar beskerming tsjin split-brain standert Pacemaker technology neamd STONITH (Sjit de oare knooppunt yn 'e holle) of fêsting. Syn essinsje: as de knooppunten yn it kluster begjinne te fermoedzjen dat der wat mis is mei in knooppunt, it reagearret net of is ferkeard gedraacht, dan skeakelje se it mei geweld út fia "eksterne" apparaten, bygelyks in IPMI- of UPS-kontrôlekaart . Mar dit sil allinich wurkje yn gefallen wêr't, yn it gefal fan in inkelde flater, de IPMI- of UPS-tsjinner trochgiet te wurkjen. Hjir binne wy ​​fan plan om te beskermjen tsjin in folle mear katastrofale mislearring, as it hiele datasintrum mislearret (bygelyks ferliest macht). En mei sa'n wegering, alles stonith-apparaten (IPMI, UPS, ensfh) sil ek net wurkje.

Ynstee dêrfan is it systeem basearre op it idee fan quorum. Alle knooppunten hawwe in stim, en allinich dejingen dy't mear as de helte fan alle knooppunten kinne sjen kinne wurkje. Dizze kwantiteit fan "heal + 1" wurdt neamd quorum. As it kworum net berikt wurdt, dan beslút it knooppunt dat it yn netwurkisolaasje is en moat syn boarnen útsette, d.w.s. dit is wat it is split-brain beskerming. As de software dy't ferantwurdlik is foar dit gedrach net wurket, dan sil in wachthûn, bygelyks basearre op IPMI, moatte wurkje.

As it oantal knooppunten even is (in kluster yn twa datasintra), dan kin saneamde ûnwissichheid ûntstean 50% / 50% (fyftich-fyftich) as netwurk isolaasje dielt it kluster krekt yn 'e helte. Dêrom, foar in even oantal knopen, foegje wy ta quorum apparaat is in unemanding daemon dat kin wurde lansearre op de goedkeapste firtuele masine yn in tredde data sintrum. Hy jout syn stim oan ien fan de segminten (dy't hy sjocht), en dêrmei oplost de 50% / 50% ûnwissichheid. Ik neamde de tsjinner wêrop it quorum-apparaat sil wurde lansearre tsjûge (terminology fan repmgr, ik fûn it leuk).

Boarnen kinne fan plak nei plak ferpleatst wurde, bygelyks fan defekte servers nei sûne, of op kommando fan systeembehearders. Sadat kliïnten witte wêr't de boarnen dy't se nedich binne lizze (wêr te ferbinen?), driuwende IP (float IP). Dit binne IP's dy't Pacemaker om knooppunten kin ferpleatse (alles is op in plat netwurk). Elk fan harren symbolisearret in boarne (tsjinst) en sil lizze wêr't jo moatte ferbine om tagong te krijen ta dizze tsjinst (yn ús gefal, in databank).

Tuchanka1 (sirkwy mei ferdichting)

struktuer

It idee wie dat wy hawwe in protte lytse databases mei lege lading, dêr't it is net rendabel te behâlden in tawijd slave tsjinner yn hot standby modus foar lêzen allinne transaksjes (der is gjin ferlet fan sa'n fergriemerij fan middels).

Elk datasintrum hat ien tsjinner. Elke tsjinner hat twa PostgreSQL-eksimplaren (yn PostgreSQL-terminology wurde se klusters neamd, mar om betizing te foarkommen sil ik se eksimplaren neame (nei analogy mei oare databases), en ik sil allinich Pacemaker-klusters klusters neame). Ien eksimplaar wurket yn master modus, en allinnich it leveret tsjinsten (allinich float IP liedt ta it). It twadde eksimplaar wurket as slaaf foar it twadde datasintrum, en sil allinich tsjinsten leverje as syn master mislearret. Om't meastentiids mar ien fan 'e twa (de master) tsjinsten sil leverje (fersiken útfiere), wurde alle serverboarnen optimalisearre foar de master (ûnthâld wurdt tawiisd foar de shared_buffers-cache, ensfh.), Mar sadat de twadde eksimplaar hat ek genôch boarnen (alhoewol foar suboptimale operaasje fia de cache fan it bestânsysteem) yn gefal fan mislearring fan ien fan 'e datasintra. De slaaf jout gjin tsjinsten (fiert net allinich lêzen fersiken) by normale wurking fan it kluster, sadat der gjin oarloch is foar middels mei de master op deselde masine.

Yn it gefal fan twa knooppunten is fouttolerânsje allinich mooglik mei asynchrone replikaasje, om't by syngroane replikaasje it mislearjen fan in slave sil liede ta it stopjen fan 'e master.

Mislearjen fan tsjûge

Net tsjûgje (quorum apparaat) Ik sil allinich beskôgje foar it Tuchanka1-kluster, mei alle oaren sil it itselde ferhaal wêze. As tsjûge mislearret, sil neat feroarje yn 'e klusterstruktuer, alles sil trochgean op deselde manier te wurkjen. Mar it kworum sil 2 fan 3 wurde, en dêrom sil elke folgjende mislearring fataal wêze foar it kluster. It sil noch driuwend reparearre wurde moatte.

Tuchanka1 wegering

Mislearring fan ien fan 'e datasintra foar Tuchanka1. Yn dit gefal tsjûge jout syn stim nei in twadde knooppunt yn in twadde datasintrum. Dêr feroaret de eardere slaaf yn in master, as gefolch, beide masters wurkje op deselde server en har beide float-IP's wize op har.

Tuchanka 2 (klassyk)

struktuer

Klassike skema fan twa knopen. De master wurket oan ien, de slaaf oan 'e twadde. Beide kinne fersiken útfiere (de slaaf wurdt allinich lêzen), sadat beide wurde oanwiisd troch float IP: krogan2 is de master, krogan2s1 is de slaaf. Sawol de master as de slaaf sille skuldtolerânsje hawwe.

Yn it gefal fan twa knooppunten is fouttolerânsje allinich mooglik mei asynchrone replikaasje, om't mei syngroane replikaasje it mislearjen fan 'e slaaf sil liede ta it stopjen fan' e master.

Tuchanka2 wegering

As ien fan 'e datasintra mislearret tsjûge stimmen foar de twadde. Op it ienige wurkjende datasintrum sil de master opheven wurde, en beide float-IP's sille derop wize: de master en de slaaf. Fansels moat it eksimplaar sa ynsteld wurde dat it genôch middels hat (ferbiningsgrinzen, ensfh.) Dat is, by normale operaasje moat it in foldwaande oanbod fan grinzen hawwe.

Tuchanka4 (in protte slaven)

struktuer

Al wer in ekstreem. D'r binne databases dy't in protte allinich-lêsoanfragen ûntfange (in typysk gefal fan in side mei hege lading). Tuchanka4 is in situaasje wêryn d'r trije of mear slaven kinne wêze om sokke fersiken te behanneljen, mar noch net te folle. Mei in heul grut oantal slaven sil it nedich wêze om in hiërargysk replikaasjesysteem út te finen. Yn it minimale gefal (op 'e foto) hat elk fan' e twa datasintra twa servers, elk mei in PostgreSQL-eksimplaar.

In oar skaaimerk fan dit skema is dat it al mooglik is om ien syngroane replikaasje te organisearjen. It is konfigurearre om, as it mooglik is, te replikearjen nei in oar datasintrum, ynstee fan in replika yn itselde datasintrum as de master. De master en elke slaaf wurde oanwiisd troch in float IP. Gelokkich, tusken slaven sil it nedich wêze om fersiken op ien of oare manier te balansearjen sql proxy, bygelyks, oan de klant kant. Ferskillende soarten kliïnten kinne ferskate soarten fereaskje sql proxy, en allinich kliïntûntwikkelders witte wa't wat nedich is. Dizze funksjonaliteit kin wurde ymplementearre troch in eksterne daemon of troch in client bibleteek (ferbining pool), ensfh. Dit alles giet fierder as it ûnderwerp fan in failover-databasekluster (failover SQL proxy kin ûnôfhinklik wurde ymplementearre, tegearre mei klantfouttolerânsje).

Tuchanka4 wegering

As ien datasintrum (dat wol sizze twa servers) mislearret, stimt tsjûge foar de twadde. As gefolch binne d'r twa tsjinners dy't rinne yn it twadde datasintrum: ien rint in master, en de master float IP wiist derop (foar it ûntfangen fan lês-skriuwfersiken); en op 'e twadde tsjinner is d'r in slaaf dy't rint mei syngroane replikaasje, en ien fan 'e slaaf float-IP's wiist derop (foar allinnich-lêzen fersiken).

It earste ding om op te merken is dat net alle slave-float-IP's arbeiders sille wêze, mar mar ien. En om der goed mei te wurkjen sil dat nedich wêze sql proxy omlaat alle oanfragen nei de ienige oerbleaune float IP; en as sql proxy nee, dan kinne jo alle float IP-slaven skieden troch komma's yn 'e ferbinings-URL listje. Yn dit gefal, mei libpq de ferbining sil wêze nei it earste wurkjende IP, dit wurdt dien yn it automatyske testsysteem. Miskien yn oare bibleteken, bygelyks, JDBC, dit sil net wurkje en is nedich sql proxy. Dit wurdt dien om't float-IP's foar slaven ferbean wurde tagelyk op ien server te ferheegjen, sadat se lykwichtich ferdield wurde ûnder slaveservers as d'r ferskate fan har rinne.

Twad: sels yn it gefal fan in flater fan in datacenter, sil syngroane replikaasje bewarre wurde. En sels as in sekundêre mislearring optreedt, dat is, ien fan 'e twa tsjinners yn' e oerbleaune datasintrum mislearret, sil it kluster, hoewol it ophâldt mei it leverjen fan tsjinsten, noch ynformaasje behâlde oer alle tawijde transaksjes wêrfoar't it befêstiging fan 'e commit hat jûn (d'r sil gjin ferliesynformaasje wêze yn gefal fan sekundêre mislearring).

Tuchanka3 (3 datacenters)

struktuer

Dit is in kluster foar in situaasje dêr't der binne trije folslein funksjonearjende data sintra, elk fan dat hat in folslein funksjonearjende databank tsjinner. Yn dit gefal quorum apparaat net nedich. Ien datasintrum wurdt bemanne troch in master, de oare twa wurde bemanne troch slaven. Replikaasje is syngroane, type ANY (slave1, slave2), dat is, de kliïnt sil in commit befêstiging krije as ien fan 'e slaven de earste is dy't reagearret dat hy de commit hat akseptearre. Boarnen wurde oanjûn troch ien float IP foar de master en twa foar slaven. Oars as Tuchanka4 binne alle trije float-IP's fouttolerant. Om allinich lêzen SQL-fragen te balansearjen kinne jo brûke sql proxy (mei aparte skuld tolerânsje), of tawize ien slave float IP oan de helte fan de kliïnten, en de oare helte oan de twadde.

Tuchanka3 wegering

As ien fan 'e datasintra mislearret, bliuwe twa oer. Yn ien wurde de master en float IP fan 'e master ferhege, yn' e twadde - de slave en beide slave float IP's (it eksimplaar moat in dûbele reserve fan boarnen hawwe om alle ferbiningen fan beide slave float IP's te akseptearjen). Syngroane replikaasje tusken masters en slaven. Ek sil it kluster ynformaasje bewarje oer tawijde en befêstige transaksjes (d'r sil gjin ferlies fan ynformaasje wêze) yn gefal fan ferneatiging fan twa datasintra (as se net tagelyk wurde ferneatige).

Ik besleat gjin detaillearre beskriuwing fan 'e triemstruktuer en ynset op te nimmen. Elkenien dy't meispylje wol kin it allegear lêze yn de README. Ik jou allinich in beskriuwing fan automatisearre testen.

Automatysk testsysteem

Om de fouttolerânsje fan klusters te testen troch ferskate fouten te simulearjen, is in automatysk testsysteem makke. Lansearre troch skript test/failure. It skript kin as parameter de oantallen klusters nimme dy't jo wolle testen. Bygelyks dit kommando:

test/failure 2 3

sil allinne testen de twadde en tredde kluster. As parameters net oantsjutte binne, dan wurde alle klusters hifke. Alle klusters wurde testen yn parallel, en it resultaat wurdt werjûn yn de tmux paniel. Tmux brûkt in tawijd tmux-tsjinner, sadat it skript kin wurde útfierd fan ûnder standert tmux, wat resulteart yn in geneste tmux. Ik advisearje it terminal te brûken yn in grut finster en mei in lyts lettertype. Foardat it testen begjint, wurde alle firtuele masines weromrôle nei in momintopname op it momint dat it skript foltôget setup.

De terminal is ferdield yn kolommen neffens it oantal klusters dat wurdt hifke; standert (yn 'e skermôfbylding) binne d'r fjouwer. Ik sil de ynhâld fan 'e kolommen beskriuwe mei it foarbyld fan Tuchanka2. De panielen yn 'e skermôfbylding binne nûmere:

1. Teststatistiken wurde hjir werjûn. Pylder:
   • mislearring - de namme fan 'e test (funksje yn it skript) dy't de fout emulearret.
   • reaksje - aritmetyske gemiddelde tiid yn sekonden wêryn't it kluster syn funksjonaliteit weromhelle. It wurdt mjitten fan it begjin fan it skript dat in fout emulearret oant it momint dat it kluster syn funksjonaliteit herstelt en kin trochgean mei it leverjen fan tsjinsten. As de tiid tige koart is, bygelyks seis sekonden (dit bart yn klusters mei ferskate slaven (Tuchanka3 en Tuchanka4)), betsjut dit dat de fout wie op 'e asynchrone slaaf en hat gjin ynfloed op de prestaasjes op ien of oare manier; der wiene gjin cluster steat skakelaars.
   • ôfwiking - toant de sprieding (krektens) fan 'e wearde reaksje mei help fan de standertdeviaasje metoade.
   • telle - hoefolle kearen dizze test waard útfierd.
2. In koarte log kinne jo evaluearje wat it kluster op it stuit docht. It iteraasje (test) nûmer, tiidstempel en namme fan 'e operaasje wurde werjûn. Te lang rinnen (> 5 minuten) jout in probleem oan.
3. hert (hert) - aktuele tiid. Foar fisuele beoardieling fan prestaasjes master De hjoeddeistige tiid wurdt konstant skreaun nei syn tabel mei de float IP-master. As suksesfol, wurdt it resultaat werjûn yn dit paniel.
4. slaan (puls) - "hjoeddeistige tiid", dy't earder waard opnommen troch it skript hert masterje, no lêze fan slaaf fia syn float IP. Stelt jo yn steat om de prestaasjes fan 'e slaaf en replikaasje visueel te beoardieljen. Yn Tuchanka1 binne d'r gjin slaven mei float IP (gjin slaven dy't tsjinsten leverje), mar d'r binne twa eksimplaren (DB's), dus it sil hjir net werjûn wurde slaanen hert twadde ynstânsje.
5. Kontrolearje kluster sûnens mei help fan it hulpprogramma pcs mon. Toant de struktuer, ferdieling fan boarnen oer knopen en oare nuttige ynformaasje.
6. Systeemmonitoring fan elke firtuele masine yn it kluster wurdt hjir werjûn. D'r kinne mear sokke panielen wêze ôfhinklik fan hoefolle firtuele masines it kluster hat. Twa grafiken CPU Load (firtuele masines hawwe twa processors), firtuele masine namme, Systeem Load (neamd Load Average omdat it is gemiddeld oer 5, 10 en 15 minuten), proses data en ûnthâld tawizing.
7. Spoar fan it skript dat testen útfiert. Yn it gefal fan in steuring - in hommels ûnderbrekking fan operaasje of in einleaze wachtsyklus - hjir kinne jo sjen de reden foar dit gedrach.

Testing wurdt útfierd yn twa stadia. Earst giet it skript troch alle soarten testen, willekeurich selektearjen fan in firtuele masine wêrop dizze test tapast wurdt. Dan wurdt in einleaze syklus fan testen útfierd, de firtuele masines en de fout wurde elke kear willekeurich selektearre. Ynienen beëiniging fan it testskript (ûnderste paniel) of in einleaze lus fan wachtsjen op wat (> 5 minuten útfieringstiid foar ien operaasje, dit kin sjoen wurde yn it spoar) jout oan dat guon fan 'e testen op dit kluster mislearre binne.

Elke test bestiet út de folgjende operaasjes:

1. Launch in funksje dy't in flater emulearret.
2. Klear? - wachtsje op it kluster om te restaurearjen (as alle tsjinsten wurde levere).
3. Toant de klusterhersteltiid (reaksje).
4. Meitsje - it kluster wurdt "reparearre." Dêrnei moat it werom nei in folslein operasjonele steat en klear wêze foar de folgjende malfunction.

Hjir is in list mei tests mei in beskriuwing fan wat se dogge:

• ForkBomb: Makket "Ut ûnthâld" mei in gaffelbom.
• Gjin romte mear: De hurde skiif is fol. Mar de test is nochal symboalysk; mei de ûnbidige lading dy't wurdt makke tidens testen, mislearret PostgreSQL normaal net as de hurde skiif fol is.
• Postgres-KILL: deadet PostgreSQL mei it kommando killall -KILL postgres.
• Postgres-STOP: hinget PostgreSQL kommando killall -STOP postgres.
• Útskeakelje: "de-energizes" de firtuele masine mei it kommando VBoxManage controlvm "виртуалка" poweroff.
• Reset: oerladen de firtuele masine mei it kommando VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: suspend de SBD-demon mei it kommando killall -STOP sbd.
• Ofslúte: stjoert in kommando nei de firtuele masine fia SSH systemctl poweroff, it systeem slút graceful ôf.
• UnLink: netwurk isolaasje, kommando VBoxManage controlvm "виртуалка" setlinkstate1 off.

Testen foltôgje mei it standert tmux kommando "kill-window" Ctrl-b &, of it kommando "detach-client". Ctrl-b d: op dit punt einiget testen, tmux slút, firtuele masines wurde útskeakele.

Problemen identifisearre tidens testen

• Op dit stuit watchdog demon sbd wurket op it stopjen fan waarnommen daemons, mar net befrieze se. En, as gefolch, defekten dy't allinich liede ta befriezing Corosync и pacemaker, mar net hingjen sbd. Foar kontrôle Corosync hat al PR#83 (op GitHub at sbd), akseptearre foar de tried master. Se tasein (yn PR # 83) dat der soe wêze wat ferlykber foar Pacemaker, Ik hoopje dat troch Red Hat 8 sil dwaan. Mar sokke "storingen" binne spekulatyf en kinne maklik keunstmjittich simulearre wurde mei help fan, bygelyks, killall -STOP corosync, mar nea moetsje yn it echte libben.

• У pacemaker yn de ferzje foar CentOS 7 ferkeard ynsteld sync_timeout у quorum apparaat, dêrtroch as ien knooppunt mislearre, mei guon kâns de twadde knooppunt ek opnij opstarte, dêr't de master nei ferhúzje soe. Genêzen troch fergrutting sync_timeout у quorum apparaat tidens ynset (yn skript setup/setup1). Dit amendemint waard net akseptearre troch de ûntwikkelders pacemaker, ynstee hawwe se tasein de ynfrastruktuer op sa'n manier te ûntwerpen (op guon net spesifisearre takomst) dat dizze timeout automatysk berekkene wurde soe.

• As de databank konfiguraasje spesifisearret dat LC_MESSAGES (tekst berjochten) Unicode kin brûkt wurde, bgl. ru_RU.UTF-8, dan by it opstarten postgres yn in omjouwing wêr't de lokaasje net UTF-8 is, sis yn in lege omjouwing (hjir pacemaker+pgsqlms(paf) rint postgres), dan it log sil befetsje fraachtekens ynstee fan UTF-8 letters. De PostgreSQL-ûntwikkelders binne net iens oer wat te dwaan yn dit gefal. It kostet, jo moatte ynstallearje LC_MESSAGES=en_US.UTF-8 by it konfigurearjen (oanmeitsjen) fan in databankeksimplaar.

• As wal_receiver_timeout is ynsteld (standert is it 60s), dan tidens de PostgreSQL-STOP-test op 'e master yn' e tuchanka3- en tuchanka4-klusters replikaasje makket gjin ferbining mei de nije master. Replikaasje dêr is syngroane, dus net allinnich de slaaf stopt, mar ek de nije master. Wurket om troch it ynstellen fan wal_receiver_timeout=0 by it konfigurearjen fan PostgreSQL.

• Sa no en dan haw ik replikaasje befriest yn PostgreSQL yn 'e ForkBomb-test (ûnthâldoerstreaming). Nei ForkBomb kinne soms slaven net opnij ferbine mei de nije master. Ik haw dit allinich yn 'e tuchanka3- en tuchanka4-klusters tsjinkaam, wêr't de master beferzen is troch syngroane replikaasje. It probleem gong nei in lange tiid (sawat twa oeren) út himsels. Mear ûndersyk is nedich om dit te korrigearjen. De symptomen binne fergelykber mei de foarige bug, dy't feroarsake wurdt troch in oare reden, mar mei deselde gefolgen.

Krogan foto nommen út deviant Art mei tastimming fan de skriuwer:

Boarne: www.habr.com