MySQL Multi Master

hello

nálam jobban hozzáértőket kérdezném, hogy melyik jobb és miért?

 

multi master

aktiv master - passziv master

aktiv master - aktiv master

Hozzászólások

Mi a feladat amihez méred a jóságát?

Mikor SQL-t es multi-mastert hasznal valaki egy mondatban, mindig ovatosan. Ez egy borzalmas hack; a SQL tranzakcio miatt logikailag nem tud tisztesseges multi-mastert csinalni, csak ha felad valamit erte (teljesitmeny vagy konzisztencia).

Annak a sebessege a beka ulepe alatt keresendo.

Az elosztott kétfázisú tranzakció nyilván mindig lassabb, de vannak esetek, amikor kell. Ha nem engedheted meg se a kiesést, se az elvesztett tranzakciókat, se az integritás elvesztését, akkor nincs nagyon más lehetőséged és minden más opció lassabb vagy rosszabb lesz.

Szóval továbbra is érdekel, hogy miért nem tisztességes SQL esetén ez a dolog.

De, rengeteg lehetoseg van, csak nyilvan nem a megkovult SQL keretein belul.

Pl. tervezhetsz olyan adatmodellt, ahol lehetseges teljesen elkuloniteni domain object-eket (meg nemi duplikacio aran is, a'la nosql). ekkor lehetseges szetszorni a domain objecteket akarhany szerverre, es egy, egyetlen DB node-on levo write lock-al megoldhato a konzisztencia.

De ha ezt igy megcsinalod, akkor mar rogton mongo-zhatsz is, mert az is ezt csinalja.

Nekem van egy olyan érzésem, hogy neked megtetszett a MongoDB és most mindent abban akarsz megoldani.

De, rengeteg lehetoseg van, csak nyilvan nem a megkovult SQL keretein belul.

Meg lehet oldani nagyon sok mindent a megkövült SQL keretein belül is. És még csak nem is lesz jelentős teljesítményvesztés belőle.

Pl. tervezhetsz olyan adatmodellt, ahol lehetseges teljesen elkuloniteni domain object-eket (meg nemi duplikacio aran is, a'la nosql). ekkor lehetseges szetszorni a domain objecteket akarhany szerverre, es egy, egyetlen DB node-on levo write lock-al megoldhato a konzisztencia. De ha ezt igy megcsinalod, akkor mar rogton mongo-zhatsz is, mert az is ezt csinalja.

Ami addig fasza, amíg ki nem esik terhelés közben a primary node és megy a sakkozás, hogy ki lesz a következő primary és mennyi van neki meg abból, amit az előző primary tudott... NoSQL esetén ugyanúgy jelentős alkalmazásoldali logikákkal tudsz csak ilyet megoldani és akkor ott tartasz, amit mondtál is: "App szinten meg mukodhet, de akkor meg kitolod a komplexitast a kodba, amit a helyi IT-sek butykolnek, nem jo otlet (v.o. 'error-prone')."

10 evvel ezelott vegeztem a mongodb 101j-t, es azota boldog vagyok vele. Ez nem valami kezdo it-s boldogsaga.

Erteni kell hozza, mint mindenhez. Tapasztalataim szerint sajnos sok dev belekovult a sql-be es a schema-ba, es ez az atmenetet nagyon megneheziti, gyakran lehetetlenne teszi. Okos, intelligens embereknek is komoly gondja van azzal, hogy hirtelen mashogy kene tervezni mindent.

En meg olyan projektet nem lattam, ami bonyibb, mint egy microservice, es nem lett gond a sql problemakbol (skalazodas/adatmodell/teljesitmeny). A szokasos sql nyalanksagokrol nem is beszelve, mint a transaction isolation miatti gondok, vagy hogy kb. senki sehol nem ir hibakezelo kodot a commit() -hoz (tapasztalat sok-sok kod alapjan). Ilyet, hogy esetleg auto-retry, kb. 1 helyen lattam, amit en irtam.

10 evvel ezelott vegeztem a mongodb 101j-t, es azota boldog vagyok vele.

Négy éve tud a MongoDB egyáltalán tranzakciót kezelni, de ott is töredékét annak, amit egy szolid SQL cluster tud. Szóval 10 évből 6 évig úgy lehettél boldog vele, hogy

a, olyan feladataid voltak, ahol nem kellett tranzakciókkal foglalkozni,
b, megkókányoltad valahogy az alkalmazás szintjén.

A MongoDB nem silver bullet, még a NoSQL területen is van egy csomó egyéb megoldás, ami adott feladatra sokkal jobban illeszkedik, mint a MongoDB, szóval, ha olyan érzésed van, hogy minden is meg lehet és kell benne csinálni, akkor valahol valami nagyon félrement.

A szokasos sql nyalanksagokrol nem is beszelve, mint a transaction isolation miatti gondok, vagy hogy kb. senki sehol nem ir hibakezelo kodot a commit() -hoz (tapasztalat sok-sok kod alapjan).

Miért, a MongoDB ezt automatikusan megoldja? Ja, ott nincs is értelmes transaction isolation, azt is magad kell lekezeld, ha felmerül rá az igény. A boldogságot sokszor az adja, hogy fel se merül az igénye.

Utoljara ismetlem: vegezz el egy kurzust, mielott olyan dolgokrol beszelsz, amirol fogalmad sincs.

A mongodb update-k nagyon-nagyon komplexek, ahogy a dokument alapu modellje is. Egy-egy update atomikusan vegrehajtott, ez garantalt. Azert nem volt szuksegem sose tranzakciokra, mert amig sql-ben 50 tablaval oldasz meg valamit, itt 1 dokumentum van, ergo a beolvas/modosit/kiir modell tokeletesen mukodik. Es mivel 1 doksi van, nem 50 tabla, az irasok szupergyorsak, mert csak 1 app-dbms round-trip van. Az utkozesek megoldhatoak egy 'version' mezovel, amit update-kor lehet csekkelni (atomikusan).

Meg lehet oldani nagyon sok mindent a megkövült SQL keretein belül is. És még csak nem is lesz jelentős teljesítményvesztés belőle.

Meg lehet oldani mindent cobolban es fortranban is. Meg z390 assemblyben is. Nagy cegek oskovulet rendszerei is abban vannak, es meg mindig mukodnek!!!1!!!!1!!

A kerdes nem ez, hanem az, hogy produktiv-e.

Ami addig fasza, amíg ki nem esik terhelés közben a primary node és megy a sakkozás, hogy ki lesz a következő primary és mennyi van neki meg abból, amit az előző primary tudott..

Szerintem vegezz el egy mongo traininget, ingyen van, csak nemi energia kene hozza, es maris nem irnal hulyeseket (bocs). Ez konfigolhato, igeny fuggvenyeben, google:// j=1 w=1

Szerintem vegezz el egy mongo traininget, ingyen van, csak nemi energia kene hozza, es maris nem irnal hulyeseket (bocs).

Most már tényleg igyekezni fogok elvégezni valami Udemy tanfolyást, ahol egy indiai fószer felolvassa a 3.6-os MongoDB kézikönyvet, mert vélhetően komoly hiányosságaim vannak.

Miért, szerinted mi történik akkor, amikor döglődik vagy akár kiesik a primary írás közben? Szerintem szükségszerűen átmegy a kliens oldalra a state tartása a hiba detektálásával, ha meg a kliens oldalon nem tudnak state-et tartani, akkor veszélybe kerülhet az integritás. Egy secondary node aszinkron replikálja a primary node adatait, ha döglődik vagy kiesik a primary, akkor a secondary node halmaz lesz majd valamilyen állapotban, mind más-más állapotban, és mire szavaznak maguknak egy új primary node-ot, addig nincs írási művelet, addig komplett állás van írásra abban a shard-ban. És ezek után semmi nem garantálja, hogy az új primary node ugyanazon adatok birtokában van, mint a régi primary node, mert nincs közöttük valódi szinkron replikáció. 4.4 óta van egyáltalán pre-warm lehetőség a potenciálisan választható secondary node esetén, ami kicsit kevésbé aszinkron primary követést tesz lehetővé, de ez se szinkron.

És tegyük hozzá, hogy a multi-document transaction csak úgy van támogatva, hogy közben egyedül a primary node ír és olvas és vár. Ha kell multi-document tranzakció, akkor egy shard esetén gyakorlatilag egy node-ra van korlátozva a teljesítményed, az olvasást se tudod disztributálni, és multi-shard transaction esetén ez még fájdalmasabb teljesítmény degradációt jelent. Szélsőséges esetben, ha csak multi-shard és multi-document tranzakcióid vannak, akkor egy node teljesítményének a felére esik a cluster teljesítménye, legyen benne akármennyi node, mert nincs ingyen ebéd, nincsenek csodák.

Ez konfigolhato, igeny fuggvenyeben, google:// j=1 w=1

Ennek a fentinek kurvára nincs köze ahhoz, hogy épp mennyi a write acknowledgement és van-e journal, MongoDB 5.0 óta van értelmes transaction coordinator, arbiter támogatással, előtte a multi-shard és multi-document transaction megvárta az _összes_ érintett node válaszát. És persze vannak bajok a "majority" esetén is, hiába jobb teljesítmény, ott a note a dokumentációban is: If you specify a "majority" write concern for a multi-document transaction and the transaction fails to replicate to the calculated majority of replica set members, then the transaction may not immediately roll back on replica set members.

Röviden és magyarul: ha valami gebasz van, akkor a helyreállításig lehetnek integritási problémáid és adott esetben meg is maradnak. És ez az 5.0 MongoDB, előtte a primary node volt az, amin keresztül ment minden és minden érintett node-ot meg kellett várni, hogy lement-e nála az elosztott kétfázisú commit első fázisa és nincs ellenvetése a második fázissal.

*yawn*

primary kiesesekor a kliens kap egy transierterror-t, @retryable ujracsinalja az egeszet, amire a kliens odajut, mar megvolt az election es van uj master. a microservice kliensei ebbol semmit se latnak, csak hogy picivel tovabb tart a rest query.

tranzakciot sose hasznaltam, es nem is szukseges; microservice adatmodellje tokeletes fedesben van a mongo dokumentummal, aminek update-je atomikus.

viszont nincs semmilyen ORM, schema meg hasonlo faszakodas; tenylegesen kodsorok ezreit takaritod meg, a sebessegrol es kod komplexitasrol nem is beszelve.

mongo-ba patkoltak tranzakciot, az igaz, de senki se mondta, hogy hasznald, mert alapvetoen szopas az egesz, akarcsak sql-nel. nincs ingyen ebed.

microservice adatmodellje tokeletes fedesben van a mongo dokumentummal, aminek update-je atomikus

Jó, ezt értjük. Most akkor mi van azokkal az adatmodellekkel, amik nincsenek tökéletes fedésben a mongodb tudásával? Azokat a microservice-eket hogyan implementálod mongodb felett? A nyilvánvaló válasz az, hogy sehogy. Tehát ha az üzleti igény olyan adatmodellt dob ki, amit ezzel nem tudsz megoldani, akkor vagy nem használsz mongodb-t (én nyilván rögtön erre szavaznék), vagy írsz egy ad-hoc adatbáziskezelőt, ami maga alatt mongodb-kompatibilis adatmodellt használ, hogy azt aztán lehessen mongodb-ben tárolni (ennél meg már sokkal egyszerűbb egy rendes adatbáziskezelőt használni).

Szerkesztve: 2022. 07. 09., szo – 07:04

a multi-master ki fog akadni, ha ugyanazt az adatot updateled mindkét masteren.

 

a mysql tud "semi synchronous replication"-t... ami arra jó, hogy a master elvileg commitnál megvárja a másik mastert... ha a konzisztencia lenne a cél

igy van, tapasztaltam... ezt csak ugy szabad hasznalni, ha csak az egyik szerverre mennek (iras) requestek, a masik csak tartalek. tehat kell valami IP failover (pl. keepalived) is koze, ami atkapcsol ha kell, de egyszerre nem lehet mind2 szerver elerheto. vagy mysql-proxy.

ha igazi mysql clustert akarsz, akkor galera, de ahhoz legalabb 3 szerver kell.

És/vagy a másodlagos mysql szerverek csak olvasási parancsokat fogadnak, (még) gyorsabb olvasást eredményezve. Az alkalmazásnak tudnia kell, hogy melyik session/művelet melyik connection-ön hajtható végre. Mivel a replikációnak (master-slave) van végrehajtási ideje, az írásod nem biztos hogy látszik az olvasós node-on, ezért javaslat, hogy ha van benne írás, akkor master, ha _csak_ olvasás a művelet, akkor lehet bármely replika.

igen, de innentol nagy a felelosseg a programozon is. es en mar szivtam meg ilyennel, hiaba magyaraztam el neki hogy a 2. szerverre csak olvasas mehet, egy darabig csak az is ment, aztan egyszer valami SOS implementalando featurenel nem jutott eszebe vagy valami es betolt egy kis irast is oda (persze, hogy valami bankkartyas egyenleg feltoltes creditjeit) a 2. db-be, aztan meg ment a csodalkozas hogy inkonzisztens lett az egesz, meg eltunt a penz...

na itt van a gond :)
ha tenyleg fontosak az adatok, es azt akarod, hogy a masodlagosra csak olvasas menjen, akkor vagy read replica, es nincs update jog, vagy ha backup master, akkor meg proxy ele, es ott allitani a failovert. Csak az nem hibazik, aki nem dolgozik, igy mindent meg kell tenni, hogy ilyen ne fordulhasoon elo kodolasi hibabol. proxy, tuzfal, etc.

Szerkesztve: 2022. 07. 09., szo – 16:33

Az active-passive esetén van egy valamennyire terhelhető master, valamennyire szétosztható a load, általánosságban jó a teljesítménye, de ha elveszted az active master-t, addig állás van, tranzakciók fognak elpattanni (ha vannak) vagy lesz némi inkonzisztencia.

Az active-active esetén van elosztott tranzakció, egy hajszálnyival kevésbé terhelhető a master, valamennyire kevésbé szétosztható a load, ha kiesik az egyik active master, akkor egy darabig megy tovább minden, ha visszajön, akkor van egy darabig degradált teljesítmény, amíg összeáll újra minden, a tranzakciók rendben lemennek, nincs inkonzisztencia.

A multi-master még több teljesítményt áldoz fel arra, hogy nem kettő, hanem több master felé egy az elosztott tranzakció, de elviseli, ha több master is kiesik.

A workload függvényében eléggé változatos lehet a fenti HA megoldásoknál a teljesítmény degradáció, az is lehet, hogy bizonyos függvények nem fognak menni, szóval nem fogod megúszni, hogy ki ne próbáld.

És hogy legyen benne verejték: a legnagyobb szopás az lesz, ha van egy félig halott node a rendszerben, mert annak a teljesítménye lesz a meghatározó, ha rendesen megdöglött, az a legjobb. Eszközeid viszont nem nagyon lesznek ezt detektálni, szóval itt jönnek be mindenféle monitoring hack megoldások. 

Ha multi master-ben gondolkozol, akkor gyakorlatban felejtsd el a sql-t, es nezz korul tisztesseges, nativ cluster-elheto nosql -k kozott. Meg ha 0-rol tanulsz is mindent, akkor is joval kisebb szopas lesz.

(mondom ezt evtizedes mysql en psql tapasztalattal, mongo-t kitanulva - nem bantam meg, jo dontes volt)

adott esetben elveszik az adatbázisod integritása

... nem.

szerintem tanulj meg egy picit mielott ilyeneket mondasz. mongodb-nel pl. ingyen van total jo training, vegen plecsnivel, nekem nagyon bejott. de tetszoleges nosql course-ot talani ingyenesen, amennyit akarsz, tenyleg javaslom egyiknek a vegigcsinalasat, igen erosen tagitja az ember latomezejet.

szerintem tanulj meg egy picit mielott ilyeneket mondasz.

Igyekszem majd.

Ugye alapvetően MongoDB esetén a single-document műveletek atomiak és gyorsak, ilyenkor nem lehetsz biztos abban, hogy multi-document művelet során és után milyen állapotban van az integritásod normál működés közben, nemhogy failover esemény közben vagy után.

Lassan 3-4 éve ugyan van már multi-document tranzakció (4.0 óta azonos shard esetén, 4.2 óta shared multi-document transaction), de ezek meg pont olyan degradált teljesítményt jelentenek, mint ami minden más adatbázis esetén elosztott tranzakció esetén van, csodák nincsenek... sőt, nincs transaction demarcation, transaction boundary illetve transaction isolation lehetőséged sem, amelyek fontos dolgok adott esetben a feladat függvényében.

igen erosen tagitja az ember latomezejet

Bocsánat, de van egy olyan halvány érzésem, hogy te mostanában kóstoltál bele a NoSQL világba és mindent szögnek látsz...

A mysql multi-master egy rendkivul ronda es instabil hack, eletveszely hasznalni (pont amikor a legnagyobb szukseged volna ra fog osszedolni az egesz mint egy kartyavar), mert alapvetoen egy mezei mysql az architekturabol fakadoan nem kepes HA uzemmodra.

Ha magas rendelkezesre allasu mysql-re van szukseged akkor mindenkeppen a Percona XtraDB Cluster az elso dolog amit nezz meg.

Ez minden active-active cluster sajátossága, hogy split-brain esetén nagy baj van vagy lesz, ha viszont csak egy active node van, akkor annak kiesése és/vagy akár automatikus pótlása mindenképp valamennyi kieséssel jár. Ráadásul egy automatikus active node pótlás szintén problémát okoz, ha split-brain állapot a trigger.

Egy active-active cluster eseten egy split brain szituacioban oriasi szarban vagy mert serult az adatkonzisztenciad, es a joisten se tudja mennyi ido lesz kezzel helyrerugdalni, ha egyaltalan lehetseges.

Egy active node-nal ez a problema nem all fent, igaz hogy biztosan van kiesesed, de szinte biztos hogy gyorsan es egyszeruen megoldhato.

Szoval elesben a masodikkal jobban jarsz.

De ha valakinek valoban true mysql HA kell akkor irany az Amazon RDS (illetve ennek alternativai) vagy Percona cluster. Valoban mukodo megoldas nincs mas.

Egy active-active cluster eseten egy split brain szituacioban oriasi szarban vagy mert serult az adatkonzisztenciad, es a joisten se tudja mennyi ido lesz kezzel helyrerugdalni, ha egyaltalan lehetseges.

Igen.

Egy active node-nal ez a problema nem all fent, igaz hogy biztosan van kiesesed, de szinte biztos hogy gyorsan es egyszeruen megoldhato.

Igen.

Szoval elesben a masodikkal jobban jarsz.

Nem feltétlen jársz jobban, sőt.

Nem azért találták ki az active-active és/vagy teljesen elosztott adattárolást, mert azzal biztos csak rosszul jár mindenki és közben az adott adatbázis rendszer fejlesztői röhögnek a markukba folyamatosan, hanem azért, mert szükség van rá egy csomó esetben és csomó más esetben meg overkill. És itt jön be az, hogy kell némi gondolkodás és előrelátás ahhoz, hogy el tudd dönteni, hogy neked épp melyik kell az adott feladathoz.

Azt kijelenteni, hogy élesben csak ezzel vagy azzal jársz jól, az... hm... hát, mondjuk ki: nem feltételez széles látókört.

De ha valakinek valoban true mysql HA kell akkor irany az Amazon RDS (illetve ennek alternativai) vagy Percona cluster. Valoban mukodo megoldas nincs mas.

Egyik se "true HA", az Amazon RDS SLA simán lehet 95% alatti, maximum visszaadják az állásidőre a pénzed. Percona esetén is szimplán money back guarantee van, ezek nem "true HA" megoldások, hanem egyszerűen felhős a SaaS megoldások, aminél szó nélkül viselned kell, hogy akár napokat áll, mert ha keveset fizetsz, akkor 24 órája van a support-nak veled foglalkozni, mint válasz round-trip. Vagy nem olvastad el az EULA-t az apró betűkig és meglepődsz, amikor megáll, mint a szög.

Akkor meseld el nekem hogy pontosan mire valo az active-active mysql azon kivul hogy teves biztonsagba ringasd magad es ha szetesik (marpedig szet fog) akkor nyakig ulj a szarban. Nagyon kivancsi vagyok arra a business case-re ahol azt mondod a fonokoknek hogy hat ittvan ez a csoda ide-oda replikalt cucc, es ha szethullik akkor 0 es 24 ora kozott barmeddig allhatunk, jo esetben nem lesz adatvesztes, es erre ok aztmondjak hogy ez kell nekunk :)

A szeles latokorrel pedig lathatoan neked vannak komoly problemaid:

- A Percona Xtradb cluster nem (vagy nemcsak) SaaS hanem letoltheto free open-source szoftver a kezdetek ota, self-hostedkent barhol lehet futtatni, K8S operator is van hozza pl, stb.

AWS RDS-eket kb. 10 eve uzemeltetek az elmult 8 cegnel EU es US region-okben, soha sehol nem volt meg leallas, ugyhogy maradjunk annyiban hogy kicsit jobb a valodi rendelkezesre allasa mint egy kezzel osszekokanyolt active-active mysql-nek aminek meg csak rendes koncepcioja sincs csak egy szegeny ember vizzel foz tipusu hack az egesz.
Ja es a hivatalos rendelkezesre allas is kicsit jobb mint amit te allitasz: For all RDS instances hosted in multiple Availability Zones Amazon guarantees 99.5% uptime in any monthly billing cycle. This allows for up to 3.65 hours of downtime per month.

Akkor meseld el nekem hogy pontosan mire valo az active-active mysql azon kivul hogy teves biztonsagba ringasd magad es ha szetesik (marpedig szet fog) akkor nyakig ulj a szarban.

Arra, kérlek, hogy ha minimálisra csökkentetted a brain-split lehetőségét, akkor nagy rendelkezésére állással tudj szolgáltatni. Szóval ez a "márpedig szét fog esni" az az esetek igen nagy részében nem brain-split szétesés, hanem olyan egyszerű szétesés, aminél detektálható, hogy nem brain-split történt. Bármilyen potenciális brain-split kockázatnál meg ugyanúgy megállsz, vannak rá metrikák. Tipikusan banki core rendszerek nem szoktak állni és bizony active-active cluster a többsége.

Nagyon kivancsi vagyok arra a business case-re ahol azt mondod a fonokoknek hogy hat ittvan ez a csoda ide-oda replikalt cucc, es ha szethullik akkor 0 es 24 ora kozott barmeddig allhatunk, es erre ok aztmondjak hogy ez kell nekunk :)

Szalmabáb.

A szeles latokorrel lathatoan neked vannak komoly problemaid

Könnyen lehet, igyekszem szélesíteni majd a látókörömet.

A Percona Xtradb cluster nem (vagy nemcsak) SaaS hanem letoltheto free open-source szoftver a kezdetek ota, self-hostedkent barhol lehet futtatni, K8S operator is van hozza pl, stb.

Oszt ez miben segít, hogy
a, ne legyen brain-split,
b, ne legyen állás?

Onnan indultunk, hogy neked true HA kell, de egyik se true HA megoldás, amit javasoltál.

AWS RDS-eket kb. 10 eve uzemeltetek az elmult 8 cegnel EU es US region-okben, soha sehol nem volt meg leallas,

És? Ha valaki előjön azzal, hogy 10 éve üzemeltet dzsunka vason egy dzsunka szolgáltatnál és még soha nem volt leállás, akkor meg az a legjobb? Olvass EULA-t, SLA szekciót főleg. Én szoktam olyat, te meg jössz a best case szcenárióval.

ugyhogy maradjunk annyiban hogy kicsit jobb a valodi rendelkezesre allasa mint egy kezzel osszekokanyolt active-active mysql-nek aminek meg csak rendes koncepcioja sincs csak egy szegeny ember vizzel foz tipusu hack az egesz.

<vállvonás>Akkor hack.</vállvonás>

Ja es a hivatalos rendelkezesre allas is kicsit jobb mint amit te allitasz: For all RDS instances hosted in multiple Availability Zones Amazon guarantees 99.5% uptime in any monthly billing cycle. This allows for up to 3.65 hours of downtime per month.

Ugyanarról beszélünk? https://aws.amazon.com/rds/sla/

szétesni és split-brain működni

Dehogynem, hogyne tudna.

ha nincs (N/2)+1 aktív node, akkor nem megy. így nem lehet split-brain.

Honnan tudja a két fele, hogy mennyi az N/2+1 aktív node?

Ha "Node 1" nem látja többé a "Node 2" és "Node 3", akkor "Node 1" honnan tudja majd, hogy ő maradt egyedül (az N/2+1 igaz rá) és neki kell állni a sarat és a többiek tényleg elhaltak, vagy csak nem látja őket és közben a "Node 2" és a "Node 3" is úgy gondolja, hogy a "Node 1" halott és ők a túlélők (N/2+1 igaz rájuk)?

> Dehogynem, hogyne tudna.

pont etz mondom en is

> Honnan tudja a két fele, hogy mennyi az N/2+1 aktív node?

config filebol.

> "Node 1" honnan tudja majd, hogy ő maradt egyedül

nem latja a tobbi node-t. es mivel azt is tudja, hogy kevesebben van mint az osszes fele (1 < 3/2) igy offolja magat.

> az N/2+1 igaz rá

hogy lenne igaz ra? 3 node eseten 3/2+1 az tobb mint az 1

Nagyon jó, na pont ez történik egy három master node-os cluster-ben, az N/2+1 nem az összes tagra számolandó, hanem az összes ismert élő tagra és egész számos aritmetika, tehát kettő tag esetén a 2/2+1 az 2, egy tag esetén az 1/2+1 az 1, három tag esetén a 3/2+1 az 2.

Általában nem az az N definíciója, hanem az, hogy mennyi node él. Ha az N az összes node, akkor technikailag nincs brain-split, viszont leállás van a legkisebb hálózati hiba esetén is, csak az ellen véd, ha egy-egy node fizikai okokból kiesik.

Megfelelő hálózati architektúrával minimalizálni tudod a split-brain kockázatot, de például honnan tudod, hogy ha nem érsz el négy DC-t, akkor hétből négy DC fizikailag kiesett és a többség az kettő DC, vagy csak brain-split van, szétesett a geo-cluster egy három DC-s és egy négy DC-s részre és mindegyik úgy gondolja, hogy csak ő létezik, a többi halott? A brain-split lényege pont az, hogy nem tudod eldönteni, hogy a több részre szakadt cluster csak szétszakadt vagy valós failover van, ha el tudod dönteni (többszörösen redundáns hálózat), akkor nincs brain-split.

Ebben a rendszerben a kliensek és a szerverek is pontosan tudják, hogy hány replika van. Ha valamelyik nem elérhető, akkor tök mindegy, hogy szakadás van mert elvágták a traktorok az összes optikát vagy kiesett valaki mert aszteroida csapódott az adatközpontba. Quorummal lehet commitolni, anélkül nem, és ennyi. Olvasni a szakadás időpontjáig bármelyik replikából lehet. Paxos alapú amúgy.

Szóval ha valaki összerak egy rendszert, ahol 0-nál nagyobb esélye van a split brainnek, az elég nagy baj. Nyilván 2 node-nal nem lehet elkerülni. 3-nál/5-nél pedig meg kell oldani, hogy 2/3 replika egyetértése kell.

Ebben a rendszerben a kliensek és a szerverek is pontosan tudják, hogy hány replika van.

Oké, tisztázzuk: például van egy EU és egy US régió, ha az EU és az US régió között megszűnik a hálózati kommunikáció, akkor minden megáll?

Ha valamelyik nem elérhető, akkor tök mindegy, hogy szakadás van mert elvágták a traktorok az összes optikát vagy kiesett valaki mert aszteroida csapódott az adatközpontba.

Brain-split tipikusan akkor van, amikor a DC elérhető a saját régiójában, csak a DC-k nem érik el egymást valamiért.

Quorummal lehet commitolni, anélkül nem, és ennyi. Olvasni a szakadás időpontjáig bármelyik replikából lehet. Paxos alapú amúgy.

Attól még lehet brain-split, csak egy részét kivéded azzal, amit írtam korábban, hogy potenciális brain-split esetén megáll minden.

> Oké, tisztázzuk: például van egy EU és egy US régió, ha az EU és az US régió között megszűnik a hálózati kommunikáció, akkor minden megáll?

Páratlan számú van. Ha 3 esetén 2-1 a felállás, akkor a 2 elmegy, a harmadik kussol, és aki hozzá akar beszélni, nem fog neki sikerülni. 5 esetén 4-1, 3-2, 3-1-1 esetén működik, 2-2-1 és egyéb esetekben nem.

> A brain-split lényege pont az, hogy nem tudod eldönteni, hogy a több részre szakadt cluster csak szétszakadt

> Brain-split tipikusan akkor van, amikor a DC elérhető a saját régiójában, csak a DC-k nem érik el egymást valamiért.

Ez a kettő definíció nem ugyanaz. De akkor elmondom a saját szavaimmal. Hálózati szakadás lehet, de olyan helyzet nem állhat fent, hogy két külön klikk hiszi azt, hogy szabad írnia, és adatkorrupciót okoznak, mert a Paxos miatt pontosan tudják, hogy nem szabad írniuk.

2-2-1 és egyéb esetekben nem

Márpedig ezek az igazi problémák...

Hálózati szakadás lehet, de olyan helyzet nem állhat fent, hogy két külön klikk hiszi azt, hogy szabad írnia, és adatkorrupciót okoznak, mert a Paxos miatt pontosan tudják, hogy nem szabad írniuk.

Így van, cserébe sokkal hamarabb meg tud állni a rendszered, szóval ezt mind-mind mérlegelni kell, hogy mennyire fontos az (eventually) integrity és mennyire fontos a rendelkezésre állás és mennyire fontos mindezek sebessége, szóval a klasszikus speed-integrity-availability hármasból egyszerre csak kettőt választhatsz, szélsőséges esetben csak egyet. A brain-split kockázat ebben csak egy faktor a sok közül.

Ezek az adatbázisok adatközponton belül is kapnak egy réteg shardingot, tehát már egy adatközpont is ~100% rendelkezésre állású. Olyan még nem volt, hogy 5 replikából akár csak 2 kiesett volna, és 3-nak kellene kiesnie ahhoz, hogy ne tudjunk írni. De ez még mindig jobb, mint a korrupció. Én azt mondom, hogy a split brain okozta korrupció kockázatára csak pontosan a 0 az elfogadható, különben olyan adatbázisra nem bízunk adatot.

Ezek az adatbázisok adatközponton belül is kapnak egy réteg shardingot, tehát már egy adatközpont is ~100% rendelkezésre állású.

Kivéve, ha hálózati hiba miatt kiesik a DC-k fele plusz egy, mert akkor egészen pontosan nulla lesz a rendelkezésre állása a maradéknak, bármennyi réteg shard van ott.

Olyan még nem volt, hogy 5 replikából akár csak 2 kiesett volna, és 3-nak kellene kiesnie ahhoz, hogy ne tudjunk írni.

Na, ezek az "olyan még nem volt" állítások... ezek a legjobbak. Mindegy, hogy volt-e vagy sem, üzemeltetési kockázat, amivel számolni kell.

De ez még mindig jobb, mint a korrupció. Én azt mondom, hogy a split brain okozta korrupció kockázatára csak pontosan a 0 az elfogadható, különben olyan adatbázisra nem bízunk adatot.

Idézem magam szó szerint: "a klasszikus speed-integrity-availability hármasból egyszerre csak kettőt választhatsz, szélsőséges esetben csak egyet". Nincs ezzel baj, csak legyen tudatosítva.

> Kivéve, ha hálózati hiba miatt kiesik a DC-k fele plusz egy, mert akkor egészen pontosan nulla lesz a rendelkezésre állása a maradéknak, bármennyi réteg shard van ott.

Technically correct, de gondolom te is tudod, hogy egy teljes DC kiesése nem épp mindennapos dolog. Nálunk sem, de szerintem minden olyan helyen így van, ahol többes számban vannak DC-k. Olyannyira ritkaság, hogy arról cikket ír a világsajtó. Pl. az OVH-nál egyszer leégett egy. És ez már önmagában valami hihetetlenül ritka dolog, de hogy egy cégnél elmenjen 3, az meg főleg. Ha most azt akarod bizonyítani, hogy a rendelkezésre állás nem 100% hanem 99.99999% akkor nem kell győzködni, eddig is tudtam. Illetve ez meg a házilag tákolt MySQL clusterek között elég sok nagyságrendnyi különbség van.

> Na, ezek az "olyan még nem volt" állítások... ezek a legjobbak. Mindegy, hogy volt-e vagy sem, üzemeltetési kockázat, amivel számolni kell.

Ha tudnád, hol dolgozom, nem írnál ilyet. Maradjunk annyiban, hogy ez a rendelkezésre állás nem véletlenül ennyi. Igen, lehet, hogy egyszer pont belecsapódik 3 adatközpontba 3 aszteroida, és leáll az írás. De ennek olyan kicsi az esélye, hogy előbb fog a világ összes tákolt MySQL clustere összezuhanni. Illetve biztos kiszámolta valaki a rizikót és van vészforgatókönyv még erre is. De mondom, még mindig jobb leállítani az írást, mint engedélyezni hogy korrupcióhoz vezessen.

> Idézem magam szó szerint: "a klasszikus speed-integrity-availability hármasból egyszerre csak kettőt választhatsz, szélsőséges esetben csak egyet". Nincs ezzel baj, csak legyen tudatosítva.

Én CAP theoremként ismerek egy hasonlót. Olyan komoly helyen szerintem nincs, ahol az integritást áldoznánk fel bármiért is cserébe.

Technically correct, de gondolom te is tudod, hogy egy teljes DC kiesése nem épp mindennapos dolog.

Láttam már leégni egy egész DC-t, volt benne cuccom. Nem mindennapos, de az viszonylag gyakran előfordul, hogy egy egész DC eltűnik egy időre, bármilyen okból.

És ez már önmagában valami hihetetlenül ritka dolog, de hogy egy cégnél elmenjen 3, az meg főleg.

Egy cégnél is el tud menni, lásd Facebook több órás állás egy config hiba miatt, lásd Amazon kiesések, szintén config hiba miatt. Régiós Cloudflare letérdelés, szintén config hiba miatt. Lásd Google DNS hiba. Utóbbi egy év termése.

Ha most azt akarod bizonyítani, hogy a rendelkezésre állás nem 100% hanem 99.99999% akkor nem kell győzködni, eddig is tudtam.

Kockázatokról beszélünk, ez azért egy jelentős kockázat bagatellizálása, azon az alapon, hogy "olyan még nem volt". Olyan se volt, hogy a Facebook kompletten állt volna 6-8 órát, ha tavaly előtt bárki ezt felveti, akkor azt mondom, hogy "olyan még nem volt", aztán lett.

Ha tudnád, hol dolgozom, nem írnál ilyet. Maradjunk annyiban, hogy ez a rendelkezésre állás nem véletlenül ennyi. Igen, lehet, hogy egyszer pont belecsapódik 3 adatközpontba 3 aszteroida, és leáll az írás.

Hát, akkor Facebook, Amazon, Microsoft, Google kizárva, mert azoknál volt állás az utóbbi időben. Egy csomó startup kiesik, mert általában feláldozzák az integritást. Szabad a gazda, hol dolgozol?

Én CAP theoremként ismerek egy hasonlót. Olyan komoly helyen szerintem nincs, ahol az integritást áldoznánk fel bármiért is cserébe.

Define komoly hely... elég sok olyan hely van, ahol bizony könnyű szívvel feláldozzák az integritást és azért komoly helynek tekinthető. Az integritás nem egy szent dolog, amit nem lehet megsérteni adott esetben.

> Hát, akkor Facebook, Amazon, Microsoft, Google kizárva, mert azoknál volt állás az utóbbi időben.

Pedig köztük van a nyertes. És tudok a kiesésekről, de az adatbázist egyik sem érintette. Teljes DC kiesés is talán csak egyszer volt az utóbbi sok évben tűz miatt (nem is a szerverteremben, csak biztonsági okból lőtték le a delejt asszem). Ami fontos, az hozni szokta a sok kilences rendelkezésre állást.

> Define komoly hely... elég sok olyan hely van, ahol bizony könnyű szívvel feláldozzák az integritást és azért komoly helynek tekinthető. Az integritás nem egy szent dolog, amit nem lehet megsérteni adott esetben.

Erre szívesen vennék példákat. Biztos én is ki tudnék találni valamit, ha megerőltetem magam, de valós példa érdekelne. És nem is az érdekel, hogy MySQL-ből mit tákol össze egy kezdő, pont azt nem tekintem komolynak.

Pedig köztük van a nyertes. És tudok a kiesésekről, de az adatbázist egyik sem érintette.

Ahja, tudom, mert olyan még nem volt. Facebook is így gondolta a hálózatára, aztán egyszer csak lett olyan, ami még nem volt.

Erre szívesen vennék példákat. Biztos én is ki tudnék találni valamit, ha megerőltetem magam, de valós példa érdekelne.

Miért gondolod, hogy a komoly hely együtt kell járjon azzal, hogy konzisztencia van? Ha a Facebook, Amazon, Microsoft vagy Google az, ahol dolgozol, akkor tudnod kell, hogy ott is van mindegyiknél egy csomó adatbázis, ahol nem cél a konzisztencia, kutyát nem érdekli, hogy a lájkok száma, a keresőben egy konkrét oldal konkrét pozíciója, a keresési listában a konkrét könyv vagy bármi egyéb konzisztens-e minden felhasználóra, sokkal fontosabb annál, hogy ne legyen kiesés és gyors legyen, mint az, hogy konzisztens legyen. Igen, vannak adatbázisok, ahol fontos és szent a konzisztencia és vannak, ahol nem. 

És nem is az érdekel, hogy MySQL-ből mit tákol össze egy kezdő, pont azt nem tekintem komolynak.

Pedig vannak egészen komoly rendszerek MySQL alapokon, a booking.com például MySQL alapon fut, az is komolytalan? Miért?

> Miért gondolod, hogy a komoly hely együtt kell járjon azzal, hogy konzisztencia van?

Nem konzisztenciáról, hanem integritásról/korrupcióról beszéltem. Tudok olyan adatbázisról, ahol kevésbé gáz, ha pl. eltűnik adat, de ezek nem üzleti adatok. És még ezekre is igaz, hogy a korrupció bizonyos formái már bajt okoznak (amikor pl. egymásnak ellent mondó vagy tök fals adatok jelennek meg). Még az AI-k tanításához használt adatokra is igaz, hogy ha egy-egy mintában a normálistól sok nagyságrenddel eltérő korrupt adat lenne, vagy egy-két mező/dimenzió eltűnik, akkor az látványos minőségromláshoz vezethet. Amúgy meg nyilván mondhat az ember bármilyen általánosságot, fogsz hozzá kivételt találni. Szerintem amiről én beszélek, ott elenyésző kisebbség az, ahol ne lenne gond a korrupció. Amúgy én konzisztencia alatt a CAP-theorem C betűjét értem, és csomó rendszerünk eventually consistent, evvel nincs is semmi baj.

> Pedig vannak egészen komoly rendszerek MySQL alapokon, a booking.com például MySQL alapon fut, az is komolytalan? Miért?

Azt írtam, hogy "kezdő". Mint pl. sokan, akik ezt a fórumot írják/olvassák. Nem tudom, hogy a booking mit csinál, de ha náluk is előfordul a split brain, akkor komolytalan. Vicces lenne, ha pár foglalás eltűnne vagy megduplázódna. De feltételezem, hogy ott meg tudták ezt oldani.

Tudok olyan adatbázisról, ahol kevésbé gáz, ha pl. eltűnik adat, de ezek nem üzleti adatok.

Define, hogy mi az üzleti adat és miért fontos az üzleti adat integritása. Én például szenzor-adatokat dolgozok fel, az üzleti adat? Az adatbázisom igen-igen-igen nagy része szenzor-adatokból áll. Fontos nekem mindegyik szenzor-data? Nem. Üzleti adat? Szerintem igen.

És még ezekre is igaz, hogy a korrupció bizonyos formái már bajt okoznak (amikor pl. egymásnak ellent mondó vagy tök fals adatok jelennek meg).

És? Elviselhető, ha egy hozzászóláson néha 594, néha 595 like látszik? Ellentmondó fals adat és mégse okoz bajt, a kutyát nem érdekli. Az viszont baj, ha nincs ott a lájkok száma vagy lassan jön meg az adat.

Amúgy meg nyilván mondhat az ember bármilyen általánosságot, fogsz hozzá kivételt találni.

Baszki, te is ezt műveled. Az integritás szent és sérthetetlen, aztán kiderül, hogy mégsem. :D

csomó rendszerünk eventually consistent, evvel nincs is semmi baj.

Na, csak jönnek elő az apróságok. Az eventually inconsistent már integritást tud sérteni, akkor is, ha átmeneti.

Azt írtam, hogy "kezdő". Mint pl. sokan, akik ezt a fórumot írják/olvassák.

Egy kezdő bármilyen rendszert el tud baszni, milyen érv ez már?

Nem tudom, hogy a booking mit csinál, de ha náluk is előfordul a split brain, akkor komolytalan. Vicces lenne, ha pár foglalás eltűnne vagy megduplázódna. De feltételezem, hogy ott meg tudták ezt oldani.

Része az üzleti modellnek sokszor, hogy inkább legyen pár panasz, mint álljon a rendszer vagy szignifikánsan lassú legyen a rendszer, mert az egyedi panaszt le lehet kezelni viszonylag olcsón, egy totális leállásnak viszont nagy negatív médiavisszhangja van. És ha gyorsnak kell maradnia és mindig elérhetően, akkor általában az integritás veszik el valamennyire, akár csak annyira, ahogy írtad is, hogy eventually consistent vagy akár maradandóan inconsistent állapotban van, de az inkonzisztens adat már integritást sért, mert elvész az a biztos tudás, hogy az adat, amit kaptunk, az igaz-e vagy sem, nem lehetünk benne biztosak, hogy 594 vagy 595 lájk van a hozzászóláson, nem lehetünk benne biztosak, hogy azért jött később 594, mert valaki visszavonta a lájkot vagy azért, mert egy olyan node válaszolt, amelyik nem kapott meg egy lájkot. Ne mondd, hogy ettől nem sérült az adatbázis integritása...

2-2-1 esetben 2<3, 2<3, 1<3 - a cluster offline lesz, és üzemeltetői beavatkozásra lesz szükség. Egyébként meg 5 node esetén célszerű 2+2+1 felállásban dolgozni, a +1 az "csak" quorum, és célszerűen az egyik site-on foglal helyet úgy, hogy a másikra "átvándorolni" csak kézi beavatkozással fog. De ez is csak egy lehetőség - az egyes telephelyek, az azokat összekötő hálózati kapcsolat, az elvárt rendelkezésre állás, válaszidők, stb. is fontos - szóval clustert tervezni a workload és a környezet alapos ismerete nélkül nem igazán lehet. Vagyis lehet, de erősen szuboptimális _is_ lehet (hogy a témában igencsak járatos néhai kollégát idézzek...)

Amúgy itt komolyan gondolják, tuti van a hálózati kapcsolatokban redundancia, és azt gondolom, hogy ha csak az esélye is kialakul egy SPOF-nek, akkor az már code red. De nyilván ezt nem mindenki engedheti meg magának. Szabad engedni a rendelkezésre állásból, sebességből, de integritásból nem.

Persze, hogy kell piszkálni... Anno az IBM-es okításon is ott volt egy gondolatjelet követően, hogy kell piszkálni... Viszont ha jól építetted fel az elején, _és_ tudod, hogy mi, miért és hogyan működik, _és_ átgondolod, hogy mit akarsz, illetve mit fogsz csinálni, akkor hozzányúlhatsz - illetve akkor (és csak akkor) nyúlj hozzá.

+1 az xtradb mellett. nekem sosem volt split-brain, csak szimplán kiesett valamelyik node és kész. (persze ez nem zárja ki, hogy ne lenne sb.)

Ellenben az online DDL  nem egy áldásos dolog, bár már alakul: https://www.percona.com/blog/online-ddl-with-group-replication-in-mysql…