Enkonduko

Antaŭ iom da tempo, mi ricevis la taskon evoluigi malsukcesan grapolon por PostgreSQL, funkcianta en pluraj datumcentroj ligitaj per fibro ene de la sama grandurbo, kaj kapabla elteni la fiaskon (ekzemple, senkurentiĝo) de unu datumcentro. Kiel programaron, kiu respondecas pri misfunkciado, mi elektis korregulilo, ĉar ĉi tiu estas la oficiala solvo de RedHat por krei malsukcesajn grapojn. Ĝi estas bona ĉar RedHat provizas subtenon por ĝi, kaj ĉar ĉi tiu solvo estas universala (modula). Kun ĝia helpo, eblos provizi misfunkciadon ne nur por PostgreSQL, sed ankaŭ por aliaj servoj, ĉu uzante normajn modulojn aŭ kreante ilin por specifaj bezonoj.

Al ĉi tiu decido, akceptebla demando ekestis: kiom mistolerema estos malsukcesa grapolo? Por esplori ĉi tion, mi evoluigis testbenkon, kiu simulas diversajn misfunkciadojn sur la nodoj de la areto, atendas reakiron, restarigas la malsukcesan nodon kaj daŭrigas testadon en buklo. Komence, ĉi tiu projekto nomiĝis hapgsql, sed kun la tempo mi enuiĝis pro la nomo, kiu havas nur unu vokalon. Sekve, mi komencis nomi mistoleremajn datumbazojn (kaj flosigi IP-ojn montrantajn al ili) krogan (figuro de komputila ludo, en kiu ĉiuj gravaj organoj estas duobligitaj), kaj nodoj, aretoj kaj la projekto mem estas tuchanka (la planedo kie la kroganoj loĝas).

Administrado nun aprobis malfermu projekton por la malfermkoda komunumo sub la MIT-licenco. La README baldaŭ estos tradukita en la anglan (ĉar la programistoj de Pacemaker kaj PostgreSQL estas atenditaj esti la ĉefaj konsumantoj), kaj mi decidis eldoni la malnovan rusan version de la README (parte) en la formo de ĉi tiu artikolo.

Aretoj estas deplojitaj sur virtualaj maŝinoj VirtualaBox. Entute, 12 virtualaj maŝinoj estos deplojitaj (36GiB entute), kiuj formas 4 malsukcesajn aretojn (malsamaj opcioj). La unuaj du aretoj konsistas el du serviloj PostgreSQL situantaj en malsamaj datumcentroj kaj komuna servilo atestanto c kvoruma aparato (gastigita sur malmultekosta virtuala maŝino en tria datumcentro) kiu solvas necertecon 50% / 50%per voĉdono. La tria areto en tri datumcentroj: unu majstro, du sklavoj, ne kvoruma aparato. La kvara areto konsistas el kvar PostgreSQL-serviloj, du per datumcentro: unu majstro, la ceteraj estas kopioj, kaj ankaŭ uzas atestanto c kvoruma aparato. La kvara postvivas la fiaskon de du serviloj aŭ unu datumcentro. Ĉi tiu solvo povas esti pligrandigita al pli da kopioj se necese.

Temposervo ntpd ankaŭ reagordita por faŭltoleremo, sed ĝi uzas la metodon de ntpd (orfa reĝimo). Komuna servilo atestanto funkcias kiel centra NTP-servilo, distribuante sian tempon al ĉiuj aretoj, tiel sinkronigante ĉiujn servilojn unu kun la alia. Se atestanto malsukcesas aŭ rezultas esti izolita, tiam unu el la clusterserviloj (ene de la areto) komencos distribui sian tempon. Helpa kaŝmemoro HTTP prokurilo ankaŭ levita al atestanto, kun ĝia helpo, aliaj virtualaj maŝinoj havas aliron al Yum-deponejoj. En realeco, servoj kiel preciza tempo kaj prokurilo plej verŝajne estos gastigitaj sur dediĉitaj serviloj, kaj en la budo ili estas gastigitaj sur atestanto nur por ŝpari la nombron da virtualaj maŝinoj kaj spaco.

Versioj

v0. Funkcias kun CentOS 7 kaj PostgreSQL 11 sur VirtualBox 6.1.

Aretostrukturo

Ĉiuj aretoj estas dizajnitaj por troviĝi en pluraj datumcentroj, kunigitaj en unu plata reto kaj devas elteni fiaskon aŭ retan izolitecon de unu datumcentro. Tial estas neebla uzi por protekti kontraŭ split-brain norma Pacemaker-teknologio vokis ŜTONO (Pafu La Alian Nodon En La Kapon) aŭ skermado. Ĝia esenco: se la nodoj en la areto komencas suspekti, ke io malbonas kun iu nodo, ĝi ne respondas aŭ kondutas malĝuste, tiam ili perforte malŝaltas ĝin per "eksteraj" aparatoj, ekzemple IPMI aŭ UPS-kontrolkarto. Sed ĉi tio funkcios nur en kazoj kie, kun ununura malsukceso de la IPMI-servilo aŭ UPS, ili daŭre funkcias. Ĝi ankaŭ planas protekti kontraŭ multe pli katastrofa fiasko, kiam la tuta datumcentro malsukcesas (ekzemple, estas malenergigita). Kaj kun tia rifuzo, ĉio ŝtono-aparatoj (IPMI, UPS, ktp) ankaŭ ne funkcios.

Anstataŭe, la sistemo baziĝas sur la ideo de kvorumo. Ĉiuj nodoj havas voĉon, kaj nur tiuj, kiuj vidas pli ol duonon de ĉiuj nodoj, povas funkcii. Ĉi tiu nombro "duono + 1" estas nomita kvorumo. Se la kvorumo ne estas atingita, tiam la nodo decidas, ke ĝi estas en retizolado kaj devas malŝalti siajn rimedojn, t.e. estas tiel split-cerba protekto. Se la programaro, kiu respondecas pri ĉi tiu konduto, ne funkcias, tiam gardohundo, ekzemple, bazita sur IPMI, devus funkcii.

Se la nombro da nodoj estas para (areto en du datumcentroj), tiam la tielnomita necerteco povas ekesti 50% / 50% (kvindek kvindek) kiam retizolado dividas la areton precize en duono. Tial, por para nombro da nodoj, ĝi estas aldonita kvoruma aparato - nepostulema demono, kiu povas funkcii per la plej malmultekosta virtuala maŝino en la tria datumcentro. Li donas sian voĉon al unu el la segmentoj (kiun li vidas), kaj tiel solvas la 50%/50% necertecon. La servilon sur kiu funkcios la kvoruma aparato, mi vokis atestanto (terminologio de repmgr, mi ŝatis ĝin).

Rimedoj povas moviĝi de loko al loko, ekzemple, de misaj serviloj al utilaj, aŭ laŭ ordono de sistemadministrantoj. Por ke klientoj sciu kie troviĝas la rimedoj, kiujn ili bezonas (kie konektiĝi?), flosanta IP (flosi IP). Ĉi tiuj estas la IP-oj, kiujn Pacemaker povas movi ĉirkaŭ la nodoj (ĉio estas en plata reto). Ĉiu el ili simbolas rimedon (servon) kaj estos lokita kie vi bezonas konekti por akiri aliron al ĉi tiu servo (en nia kazo, la datumbazo).

Tuchanka1 (kunpremita skemo)

strukturo

La ideo estis, ke ni havas multajn malgrandajn datumbazojn kun malalta ŝarĝo, por kiuj estas neprofite konservi dediĉitan sklavan servilon en varma standby reĝimo por nurlegeblaj transakcioj (ne necesas tia malŝparo de rimedoj).

Ĉiu datumcentro havas unu servilon. Ĉiu servilo havas du PostgreSQL-instancojn (en PostgreSQL-terminologio, ili estas nomitaj clusters, sed por eviti konfuzon, mi nomos ilin instancoj (analogie kun aliaj datumbazoj), kaj mi nomos nur Pacemaker clusters clusters). Unu kazo funkcias en majstra reĝimo, kaj nur ĝi provizas servojn (nur flosita IP kondukas al ĝi). La dua okazo funkcias kiel sklavo por la dua datumcentro, kaj nur provizos servojn se ĝia mastro malsukcesas. Ĉar plejofte nur unu el la du okazoj (la mastro) provizos servojn (plenumo petojn), ĉiuj servilresursoj estas optimumigitaj por la majstro (memoro estas asignita por la shared_buffers kaŝmemoro, ktp.), sed tiel ke la dua okazo ankaŭ havas sufiĉajn rimedojn (kvankam por ne-optimuma laboro per la dosiersistema kaŝmemoro) en kazo unu el la datumcentroj malsukcesas. La sklavo ne disponigas servojn (ne efektivigas nurlegeblajn petojn) dum normala aretoperacio, tiel ke ekzistas neniu milito por rimedoj kun la majstro sur la sama maŝino.

En la kazo de du nodoj, faŭltoleremo estas nur ebla kun nesinkrona reproduktado, ĉar kun sinkrona reproduktado, la fiasko de la sklavo kondukos al la halto de la majstro.

malsukceso atesti

malsukceso atesti (kvoruma aparato) Mi konsideros nur por la amaso Tuchanka1, la sama rakonto estos kun ĉiuj aliaj. Se atestanto malsukcesos, nenio ŝanĝiĝos en la clusterstrukturo, ĉio daŭre funkcios same kiel ĝi funkciis. Sed la kvorumo fariĝos 2 el 3, kaj tial ĉiu sekva malsukceso estos fatala por la areto. Ĝi ankoraŭ devas esti farita urĝe.

Malakcepto Tuchanka1

Fiasko de unu el la datumcentroj por Tuchanka1. Tiuokaze atestanto donas sian voĉon al la dua nodo en la dua datumcentro. Tie, la antaŭa sklavo iĝas majstro, kiel rezulto, ambaŭ majstroj laboras sur la sama servilo kaj ambaŭ de iliaj flosaj IP-oj montras al ili.

Tuchanka2 (klasika)

strukturo

La klasika skemo de du nodoj. La mastro laboras pri unu, la sklavo laboras pri la dua. Ambaŭ povas plenumi petojn (la sklavo estas nur legata), do ambaŭ estas indikitaj per flosila IP: krogan2 estas la mastro, krogan2s1 estas la sklavo. Kaj la mastro kaj la sklavo havos faŭltoleremo.

En la kazo de du nodoj, faŭltoleremo estas nur ebla kun nesinkrona reproduktado, ĉar kun sinkrona reproduktado, la fiasko de la sklavo kondukos al la halto de la majstro.

Malakcepto Tuchanka2

Se unu el la datumcentroj malsukcesas atestanto voĉdoni por la dua. Sur la sola funkcianta datumcentro, la majstro estos levita, kaj ambaŭ flosaj IP-oj montros ĝin: majstro kaj sklavo. Kompreneble, la instanco devas esti agordita tiel, ke ĝi havas sufiĉe da rimedoj (konektlimoj, ktp.) por samtempe akcepti ĉiujn ligojn kaj petojn de la mastro kaj sklava flosilo IP. Tio estas, dum normala operacio, ĝi devus havi sufiĉan marĝenon por limoj.

Tuchanka4 (multaj sklavoj)

strukturo

Jam alia ekstremo. Estas datumbazoj, kiuj havas multajn nurlegeblajn petojn (tipa kazo de tre ŝarĝita retejo). Tuchanka4 estas situacio kie povas esti tri aŭ pli da sklavoj por trakti tiajn petojn, sed ankoraŭ ne tro multaj. Kun tre granda nombro da sklavoj, estos necese inventi hierarkian reproduktan sistemon. En la minimuma kazo (en la bildo), ĉiu el la du datumcentroj havas du servilojn, ĉiu el kiuj havas PostgreSQL-instancon.

Alia trajto de ĉi tiu skemo estas ke jam eblas organizi unu sinkronan reproduktadon ĉi tie. Ĝi estas agordita por reprodukti, se eble, al alia datumcentro, kaj ne al kopio en la sama datumcentro kiel la majstro. La majstro kaj ĉiu sklavo estas indikitaj per flosilo IP. Por bone, inter la sklavoj estos necese fari ian ekvilibron de petoj sql prokurilo, ekzemple, ĉe la klientflanko. Malsamaj specoj de klientoj povas postuli malsamajn specojn de sql prokurilo, kaj nur la klientprogramistoj scias, kiu bezonas kiun. Ĉi tiu funkcio povas esti efektivigita aŭ de ekstera demono aŭ de klientbiblioteko (konektogrupo), ktp. Ĉio ĉi estas preter la amplekso de la datumbaza malsukcesa grapolo (failover SQL-prokurilo povas esti efektivigita sendepende, kune kun klientmalsukceso).

Malakcepto Tuchanka4

Se unu datencentro (t.e. du serviloj) malsukcesas, atestanto voĉdonas por la dua. Kiel rezulto, du serviloj funkcias en la dua datumcentro: la majstro laboras sur unu, kaj la majstra flosilo IP montras al ĝi (por ricevi leg-skribi petojn); kaj sklavo kun sinkrona reproduktado funkcias sur la dua servilo, kaj unu el la sklavaj flosaj IP-oj montras al ĝi (por nurlegeblaj petoj).

La unua afero por noti: ne ĉiuj sklavaj flosaj IP-oj funkcios, sed nur unu. Kaj por ĝuste labori kun ĝi, necesos tio sql prokurilo redirektis ĉiujn petojn al la nura restanta flosilo IP; kaj se sql prokurilo ne, vi povas listigi ĉiujn flosajn IP-sklavojn apartigitajn per komoj en la koneksa URL. En tiu kazo, kun libpq la konekto estos al la unua funkcianta IP, kiel farita en la aŭtomata testa sistemo. Eble en aliaj bibliotekoj, ekzemple, JDBC, tio ne funkcios kaj estas necesa sql prokurilo. Ĉi tio estas farita ĉar flosilo IP por sklavoj estas malpermesita samtempe leviĝi sur unu servilo, tiel ke ili estas egale distribuitaj inter sklavserviloj se ekzistas pluraj da ili.

Due: eĉ en kazo de fiasko de datumcentro, sinkrona reproduktado estos konservita. Kaj eĉ se sekundara fiasko okazas, tio estas, unu el la du serviloj malsukcesas en la restanta datumcentro, la areto, kvankam ĝi ĉesas provizi servojn, ankoraŭ konservos informojn pri ĉiuj faritaj transakcioj por kiuj ĝi konfirmis la kompromison (estos estu neniu perda informo pri sekundara fiasko).

Tuchanka3 (3 datencentroj)

strukturo

Ĉi tio estas areto por situacio kie ekzistas tri plene funkciaj datumcentroj, ĉiu el kiuj havas plene funkciantan datumbazan servilon. Tiuokaze kvoruma aparato ne bezonata. Majstro laboras en unu datumcentro, kaj sklavoj laboras en la aliaj du. Replikado estas sinkrona, tajpu ANY (slave1, slave2), tio estas, la kliento ricevos konfirmon kiam iu el la sklavoj estas la unua respondi, ke li akceptis la kommit. Rimedoj estas indikitaj per unu flosilo IP por majstro kaj du por sklavoj. Male al Tuchanka4, ĉiuj tri flosaj IP-oj estas toleremaj al misfunkciadoj. Por ekvilibrigi nurlegeblajn SQL-demandojn, vi povas uzi sql prokurilo (kun aparta faŭltoleremo), aŭ asigni unu sklavan IP-flosilon al duono de la klientoj, kaj la duan al la alia duono.

Malakcepto Tuchanka3

Se unu el la datumcentroj malsukcesas, du restas. En unu, la majstro kaj flosilo IP de la majstro estas levitaj, en la dua, la sklavo kaj ambaŭ sklavaj flosilo IPs (la kazo devas havi duoblan rimedmarĝenon por akcepti ĉiujn ligojn de ambaŭ sklavaj flosilo IPs). Sinkrona reproduktado inter mastroj kaj sklavoj. Ankaŭ, la areto konservos informojn pri transakcioj faritaj kaj konfirmitaj (ne estos perdo de informoj) en kazo de detruo de du datumcentroj (se ili ne estas detruitaj samtempe).

Mi decidis ne inkluzivi detalan priskribon de la dosierstrukturo kaj deplojo. Se vi volas ludi, vi povas legi ĉion ĉi en la README. Mi donas nur priskribon de aŭtomata testado.

Aŭtomata testa sistemo

Por kontroli la toleremon de misfunkciadoj de aretoj kun imito de diversaj misfunkciadoj, oni faris aŭtomatan testan sistemon. Lanĉite per skripto test/failure. La skripto povas preni kiel parametrojn la nombrojn da aretoj, kiujn vi volas testi. Ekzemple, ĉi tiu komando:

test/failure 2 3

nur testos la duan kaj trian areton. Se parametroj ne estas specifitaj, tiam ĉiuj aretoj estos testitaj. Ĉiuj aretoj estas testitaj paralele kaj la rezulto estas montrata en la tmux-panelo. Tmux uzas diligentan tmux-servilon, do la skripto povas esti rulita de sub la defaŭlta tmux, rezultigante nestitan tmux. Mi rekomendas uzi la terminalon en granda fenestro kaj kun malgranda tiparo. Antaŭ ol komenci la testadon, ĉiuj virtualaj maŝinoj estas retrovigitaj al momentfoto kiam la skripto finiĝas. setup.

La terminalo estas dividita en kolumnojn laŭ la nombro da provitaj aretoj, defaŭlte (en la ekrankopio) estas kvar el ili. Mi priskribos la enhavon de la kolumnoj uzante Tuchanka2 kiel ekzemplon. La paneloj en la ekrankopio estas numeritaj:

1. Ĉi tie montriĝas testaj statistikoj. Parolantoj:
   • malsukceso — la nomo de la testo (funkcio en la skripto) kiu imitas la malsukceson.
   • reago — la aritmetika averaĝa tempo en sekundoj por kiu la areto restarigis sian efikecon. Ĝi estas mezurita de la komenco de la skripto, kiu emulas la malsukceson, kaj ĝis la momento, kiam la cluster restarigas sian sanon kaj kapablas daŭre provizi servojn. Se la tempo estas tre mallonga, ekzemple, ses sekundoj (ĉi tio okazas en aretoj kun pluraj sklavoj (Tuchanka3 kaj Tuchanka4)), tio signifas, ke la misfunkcio finiĝis sur nesinkrona sklavo kaj neniel influis rendimenton, ne estis; grapŝtatŝaltiloj.
   • devio - montras la disvastigon (precizecon) de la valoro reago per la metodo de norma devio.
   • kalkuli Kiom da fojoj ĉi tiu provo estis farita.
2. Mallonga protokolo permesas al vi taksi tion, kion la areto nuntempe faras. La ripeta (testa) nombro, tempomarko kaj operacionomo estas montrataj. Tro longa ekzekuto (> 5 minutoj) indikas ian problemon.
3. koro (koro) estas la nuna tempo. Por takso de vida rendimento mastroj la nuna tempo estas konstante skribita al sia tablo uzante la flosilon IP de la majstro. Se sukcesa, la rezulto montriĝas en ĉi tiu panelo.
4. batis (pulso) - "nuna tempo", kiu antaŭe estis registrita per la skripto koro majstri, nun legu de sklavo tra ĝia flosilo IP. Permesas al vi vide taksi la agadon de sklavo kaj reproduktadon. Ne estas sklavoj kun flosilo IP en Tuchanka1 (ne ekzistas sklavoj provizantaj servoj), sed estas du okazoj (DB), do ĝi ne estos montrita ĉi tie. batiskaj koro dua okazo.
5. Monitorante la staton de la areto uzante la ilon pcs mon. Montras la strukturon, distribuadon de rimedoj laŭ nodoj kaj aliajn utilajn informojn.
6. Ĝi montras sisteman monitoradon de ĉiu cluster virtuala maŝino. Eble ekzistas pli da tiaj paneloj - kiom da virtualaj maŝinoj havas la areto. Du grafikaĵoj CPU-Ŝarĝo (du procesoroj en virtualaj maŝinoj), virtuala maŝinnomo, Sistema Ŝarĝo (nomita Load Average ĉar ĝi averaĝis pli ol 5, 10, kaj 15 minutojn), procesdatenojn kaj memorasigno.
7. Spurante la skripton, kiu plenumas la testojn. Okaze de misfunkciado - subita interrompo de laboro aŭ senfina atendado - ĉi tie vi povas vidi la kialon de ĉi tiu konduto.

Testado estas farita en du etapoj. Unue, la skripto pasas tra ĉiuj specoj de testoj, hazarde elektante virtualan maŝinon al kiu ĉi tiu testo devus esti aplikita. Tiam senfina testa ciklo estas farita, virtualaj maŝinoj kaj misfunkcio estas hazarde elektitaj ĉiufoje. Subita fino de la testa skripto (malsupra panelo) aŭ senfina atenda buklo por io (> 5 minutoj da tempo por plenumi unu operacion, tio videblas en la spuro) indikas, ke kelkaj el la testoj sur ĉi tiu areto malsukcesis.

Ĉiu testo konsistas el la sekvaj operacioj:

1. Lanĉante funkcion, kiu imitas misfunkciadon.
2. Preta? - atendante la restarigon de la sano de la areto (kiam ĉiuj servoj estos faritaj).
3. La tempodaŭro de reakiro de grapo estas montrita (reago).
4. Fix - la areto estas "riparita". Post tio ĝi devus reveni al plene funkcia stato kaj preta por la sekva misfunkcio.

Jen listo de testoj kun priskribo de tio, kion ili faras:

• Forkbombo: Kreas "El memoro" per forkbombo.
• EksterSpaco: la malmola disko estas plena. Sed la testo estas sufiĉe simbola, kun la sensignifa ŝarĝo kiu estas kreita dum testado, kiam la malmola disko superfluas, PostgreSQL kutime ne malsukcesas.
• Postgres-MORTIGO: mortigas PostgreSQL per la komando killall -KILL postgres.
• postgres-HALTU: pendigas PostgreSQL kun la komando killall -STOP postgres.
• malŝalti: "malŝaltas" la virtualan maŝinon per la komando VBoxManage controlvm "виртуалка" poweroff.
• Restarigi: reŝargas la virtualan maŝinon per la komando VBoxManage controlvm "виртуалка" reset.
• SBD STOP: malakceptas la SBD-demonon per la komando killall -STOP sbd.
• Ĉesigo: per SSH sendas komandon al la virtuala maŝino systemctl poweroff, la sistemo malŝaltas gracie.
• malligi: retizolado, komando VBoxManage controlvm "виртуалка" setlinkstate1 off.

Finu testadon aŭ per la norma tmux-komando "kill-window" ctrl-b&, aŭ per komando "detach-client" ctrl-bd: samtempe, testado estas finita, tmux estas fermita, virtualaj maŝinoj estas malŝaltitaj.

Problemoj Identigitaj Dum Testado

• En ĉi tiu momento gardhundo demono sbd pritraktas ĉesigi observitajn demonojn, sed ne frostigi ilin. Kaj, kiel rezulto, misfunkcioj estas malĝuste ellaboritaj, kondukante al nur frosto Corosync и korregulilo, sed ne pendanta sbd... Por kontrolo Corosync jam havas PR#83 (en GitHub ĉe sbd), akceptita en la branĉon majstro. Ili promesis (en PR#83) ke estos io simila por Pacemaker, mi esperas ke ĝis Ruĝa Ĉapelo 8 faros. Sed tiaj "misfunkcioj" estas konjektaj, facile imiteblaj artefarite uzante, ekzemple, killall -STOP corosyncsed neniam renkontiĝas en la reala vivo.

• У korregulilo en la versio por CentOS 7 malĝuste fiksita sync_timeout у kvoruma aparato, tial se unu nodo malsukcesis, la dua nodo rekomencis kun iom da probableco, al kiu la majstro devis moviĝi. Resanigita per pligrandigo sync_timeout у kvoruma aparato dum deplojo (en skripto setup/setup1). Ĉi tiu amendo ne estis akceptita de la programistoj korregulilo, anstataŭe ili promesis relabori la infrastrukturon tiamaniere (en iu nedifinita estonteco) ke tiu tempo-tempo estas kalkulita aŭtomate.

• Se vi specifis dum datumbaza agordo tion LC_MESSAGES (tekstaj mesaĝoj) Unikodo povas esti uzata, ekzemple, ru_RU.UTF-8, tiam ĉe ekfunkciigo postgresoj en medio kie la loko ne estas UTF-8, ekzemple, en malplena medio (ĉi tie korstimulilo+pgsqlms(paf) startas postgresoj), tiam en la protokolo anstataŭ UTF-8 literoj estos demandosignoj. La programistoj de PostgreSQL neniam konsentis pri tio, kion fari en ĉi tiu kazo. Ĝi kostas, vi devas meti LC_MESSAGES=en_US.UTF-8 kiam oni agordas (kreas) DB-instancon.

• Se wal_receiver_timeout estas agordita (defaŭlte ĝi estas 60s), tiam kiam oni testas PostgreSQL-STOP sur la majstro en tuchanka3 kaj tuchanka4-grupoj Reproduktado ne rekonektas al nova majstro. Replikado tie estas sinkrona, do ne nur la sklavo ĉesas, sed ankaŭ la nova mastro. Akiras per agordo de wal_receiver_timeout=0 dum agordado de PostgreSQL.

• Mi foje observis PostgreSQL-replikadon pendantan en la ForkBomb-testo (memorsuperfluo). Post ForkBomb, foje sklavoj eble ne rekonektas al la nova majstro. Mi vidis tion nur en tuchanka3 kaj tuchanka4 aretoj, kie pro la fakto, ke reproduktado estas sinkrona, la majstro pendis. La problemo foriris per si mem, post longa tempo (ĉirkaŭ du horoj). Pli da esplorado estas necesa por ripari ĉi tion. La simptomoj estas similaj al la antaŭa cimo, kiu estas kaŭzita de malsama kaŭzo, sed kun la samaj konsekvencoj.

Krogan bildo prenita de Deviant Art kun la permeso de la aŭtoro:

fonto: www.habr.com