Pletete dohromady par ne zcela souvisejicich veci. Neni rozhodne pravdou, ze "na vrstvě blokových zařízení nelze splitbrain automatizovaně vyřešit". Split-brain je jednoznacne definovana situace ke ktere dochazi relativne casto (rekneme jednou za par let na kazdem clusteru) a kterou kazdy clusterovy software automaticky resi. Jde o ztratu meziinstancniho propoje pri zachovani funkcnosti cluster heartbeat. Reseni je posoudit stav vsech zucastnenych instanci a nasledne urcit, ktera pujde dolu a ktera prevezme cinnost. Jedinym problemem v tomto pripade je casovy usek po ktery se bude split-brain vyhodnocovat. Na jednu stranu je vhodne to udelat co nejrychleji, protoze dokud je cluster ve split-brain nelze provest zadne transakce a system je nedostupny, na druhou stranu neni ucelne pri kratkodobem vypadku provest failover, protoze to neni zrovna end user friendly operace. Cluster SW to tudiz resi nastavitelnym parametrem (obvykle radove minuty) po ktery se zastavi zpracovani a ceka se na obnoveni spoje nebo na rezignaci na nej a nevyhnutelny failover.
To o cem vy mluvite je rozpojeni clusteru pri zachovani funkcnosti obou. K necemu podobnemu v prvni rade nesmi dojit a cluster SW neco takoveho nedovoli.
Jinak bych jeste dodal, ze rozjety cluster rozhodne nevyresite na "vyssi vrstve abstrakce" at uz jde o soubory nebo o databazi. Jedine misto kde lze takovy stav vyresit je aplikacni vrstva a to jeste velmi komplikovane.
Názor k článku
Výpadek TTC ochromil 200 tisíc e-mailových schránek Seznamu
