Hibatűrő master-master sql replikációt keresek

 ( plt | 2017. május 10., szerda - 10:31 )

Keresek egy olyan, lehetőleg minél egyszerűbb SQL adatbáziskezelőt, aminek stabil a master-master replikációja.
Eddig mysql-ben használtam csak replikációt, ott is csak master-slave típusút, de annyira megbízhatatlan, hogy erre nem mernék fontosabb adatokat bízni. Olyan rendszert keresek, ami a fájlrendszer vagy hardver hibák esetén történő leállások után is képes újra szinkronba kerülni, anélkül, hogy a másik master rendszernek le kellene állnia - akár csak egy teljes dump erejéig is.

Az SQL képességek tekintetében nincsenek nagy igényeim, csak egyszerű sql műveleteket kell végrehajtani, tehát mellőzném az oracle farmok kialakítását, bár ezek bizonyosan elég megbízhatóak lennének.
Jelenleg csak a pgsql-re tudok alternatívaként gondolni, de ezzel gyakorlatilag semmilyen tapasztalatom nincs, csak a legendák, hogy mennyivel jobb mint a mysql.
Mivel csak konfigurációs adatokat fog tárolni az adatbázis, az jó lenne, ha minél gyorsabban lenne képes lefuttatni egy-egy SELECT-et. Ennek ellenére a cdb-t és egyéb nem SQL adatbázisokat kerülném, a konfigurálhatóság egyszerűsítése miatt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

+1 vagy ennek vmelyik fork-ja:
MariaDB 10.1 Galera, Percona XtraDB cluster

Egy fájl szinten kompatibilis adatbáziskezelőnek mennyivel lehet stabilabb a replikációja? Ha a Mariadb a mysql binlogjait is egy az egyben kezeli (így van?), akkor várható tőle stabilabb replikáció, mint az eredetijétől?

Vagy arra gondolsz, hogy a galera alatt ne mysql menjen, hanem mariadb?

Mariadb a MySQL forkja - bar jelnleg MariaDB tudatosan probal egyre jobban elterni MySQL-tol de az alapok meg ugyan azok.
Galera plugin nem hasznalja a binary logokat, that nem azok alapjan replikal.

nemrég került képbe ez a lehetőség, valamennyi segítség a telepítéshez, ha valakinek szüksége lenne rá:

https://www.cyberciti.biz/faq/howto-install-configure-mariadb-galera-master-cluster-ubuntulinux/


"I'd rather be hated for who I am, than loved for who I am not."

kar hogy paratlan szamu (min 3) szerver kell hozza, igy sima hot backupnak nem alkalmas :(

a mysql master-slave addig mukodik jol, amig a slavet nem bizgeted. a master-master is hasonlokepp. meg ahol csak backupnak van, ott en azt szoktam, hogy naponta vagy hetente full ujra toltom a slave-n a db-t (ugyis keszul backup a masteren, es azt betoltom a slavere) es utana a replikacio csak naprakeszen tartja. ha megallt a replikacio (es leszartam a riasztast rola) es a master is megholt akkor is max par napot bukok el.

miért megbízhatatlan a mysql master-slave replikáció?

Talán attól, hogy nem master-master... :)
--
Debian Linux rulez... :D
RIP Ian Murdock

Mert nehezen tűri a környezeti hibákat. A slave egy hányattatott környezetben üzemel, amiatt gyakran kifogy alóla az áram. 10-ből 8-szor az a megoldás, hogy új master dumpot kell készíteni, mert nem képes folytatni a replikálást. 1-szer sikerül beállítani, hogy honnan folytassa a replikálást, és talán a maradék 1 esetben képes automatán is folytatni a szinkronizálást, miután felébredt.
Ez azért nem nevezhető megbízhatónak.
Amúgy nem kétlem, hogy stabil hardver környezetben hasznos és jó eszköz.

Tegyel a slave ala egy ups-t megfelelo beallitasokkal (pl csak akkor kapcsoljon vissza ha 80%-ra feltoltott, meg persze hozzakotni a gepet) hogy aramszunet eseten le tudjon allni rendesen a szerver.
Masteren legyen meg hosszabb ideig binlog.
Tegyel monitoringot replkara ha megis gond lenne eszrevedd hamar.

A masterben van elég binlog.
Meg lehet növelni a mysql replikáció stabilitását hardver befektetéssel, de ez nem fogja garantálni, hogy kiritkus eset után felálljon automatikusan a szinkron. Maximum a problémás esetek számát fogja csökkenteni.

Ha a MySQL beallitasaid crash-safek , akkor egy aramszunetet es egyeb dolgokat problema nelkul turnie kell es ujrainditas utan folytatni a replikaciot. En eloszor a jelenlegi beallitasaid neznem meg. Barmilyen rendszert kiepithetsz ha a beallitasok nem jok akkor nem is fog jol mukodni.

Valószínűleg nem crash-safe a mysql konfigurációm. Egy alap mysql szerver, a manual alapján felépített master-slave replikációval.
A mysql adatbiztonságról állította egyszer valaki, hogy felesleges mindenféle hókuszpókusz, mivel a fájlrendszer szintű mysql mentésből 100% biztonsággal vissza lehet állni mindig. Ez a crash-safe dolog is valami hasonlónak tűnik a számomra.
Igazából nem tudom, melyik beállítása ganrantálná a mysql-nek, hogy tetszőleges áramszünet esetén is sérülésmentesen tudja folytatni, nem is a replikációt, de magát az üzemelést is. Valószínűleg itt az én tudásom kevés, és ha megosztod velem, mi teszi áramszünetbiztossá a mysql-t, ki fogom próbálni.
Jelen esetben azonban én úgy tudom, csak a replikálás, vagy a konzisztens mentés segítségével érhető ez el.

Mint a legtobb dolog ez is beallitas kerdese, az hogy marketing anyagban benne van hogy crash safe meg nem feltetlenul jelenti hogy alapbeallitasokkal vagy minden esetben.
Szerintem masold be a mysql konfigod, replikacio statust meg lehet olyan is kerdeses ezek utan, hogy pl innodb-t, myisam vagy egyebet hasznalsz-e a tablakon.

Ez nem igaz, mindig számítanak a körülmények, pl a MyISAM sose lesz crash-safe, mert nem naplóz. Az InnoDB tudja garantálni azt a naplóval, hogy amelyk commitot leokézta, az már meglesz legközelebb is.

lol. a crasht semmilyen db nem szereti, a clusterek meg annyira se. csinald meg hogy amikor elindul a slave szerver akkor toltse be a zutolso full dumpot a masterrol es onnan induljon.

ilyenkor nem az az uzenet van a slaven hogy nemtudja olvasni a relay logot, mert a logpos valami bazinagy szam?
mert ha igen, akkor konnyen javithato: show slave status-sal megnezed hol tartott a replikacio, majd :
RESET SLAVE; CHANGE MASTER TO master_log_file='mysql-bin.00XXXXX',master_log_pos=YYYYYYY; START SLAVE;

aztan egy pt-checksum & pt-table-sync-el meg fixalod az esetleges hianyzo adatokat.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Igen, és ez az a módszer, ami a 10-ből egyszer működik is.
Máskor pedig elkezdi köpni, hogy a kulcs mezőben duplikákások keletkeztek, emiatt nem tudja folytatni. Elég sok google-órát töltöttem már azzal, hogy a mysql hibaüzenetei alapján megpróbáljam helyreállítani a replikációt, mondván: így tanul a gyerek. A végén mégiscsak oda jutottam ezekben az esetekben, hogy új master dump. Mivel az áramszünet a gazda gépet érinti, amin a virtuális gép fut, lehet, hogy itt más típusú fájlrendszer konfliktus történik ... nem tudom. A lényeg, hogy nekem csak nagyritkán sikerül helyreállítanom a replikációt. Arról nem is szólva, hogy egy hibatűrésre felkészített replikációnál azért elvárható lenne, hogy a szinkront automatán megtalálja, vagyis tudja a slave, hogy meddig replikált hitelesen. Amiből meg az következik, hogy ez nem hibatűrésre kitalált replikáció, csak terheléselosztásra.

feliratkozok...

nekem 10-ből egyszer se sikerült, de "örülök" hogy másnak sem :)


// Happy debugging, suckers
#define true (rand() > 10)

Van egy olyan gyanúm, hogy az a gép egy standalone mysql-lel sem élné túl az áramszünetet. Márpedig ilyen platformon semmilyen adatbáziskezelő nem fog stabilan működni (az Oracle is csak annyit fog mondani induláskor, hogy akkor vedd elő a mentést, mert inkonzisztens lett az adatbázis).

Erre lehet az a mondása egyeseknek, hogy de rakjál alá szünetmentest, én meg azt mondom, hogy az nem elfogadható semmilyen platformtól, hogy az áram azonnali elvétele után 100-ból akár egyetlen egyszer is mentést kelljen elővenni, ergó inkább a platformszintű beállításokat kéne rendberakni.

Persze, hogy nem élné túl az áramszünetet önmagában sem. Ezért van a master, hogy ha a slave megbotlik, a masterről minden hibát javíthat.

Nade a master-slave replikáció nem erre való (más megfogalmazásban: ezt speciel nem fogja tudni orvosolni). Bármely adatbáziskezelőt nézed, az az elvárása neki, hogy a diszkről ne tűnjenek el oda kiírt adatok, amikről azt mondta az OS, hogy tuti ki van írva a diszkre. De legalábbis az a minimum, hogy ha az A blokk kiírására azt mondta az OS, hogy kint van, majd ezután elküldi a B blokkot a diszk felé, akkor az semmiképpen ne állhasson elő, hogy a B blokk valahogy kiíródik a diszkre, miközben az A blokk meg eltűnik a diszkről (sorrendhelyesség). Szerintem ez egy abszolút fair elvárás a platformmal szemben.

Hogy egy modern cucc is legyen a listaban:

http://vitess.io/overview/

Akkor már olyan is, ami nem egy meglévő cucc pofozásán alapul:
https://github.com/pingcap/tidb
https://www.cockroachlabs.com/

Ezek nagyon biztatónak tűnnek, köszönöm!

tidb faszanak tunik, thx

Kipróbáltam. Két napom ment rá a tidb-re, de mégsem indul el, még standalon módban sem a leírás alapján. Gondolom, nagyon zaklatja, hogy debian 8-ra akarom telepíteni. Pedig amúgy jónak tűnik. Ha valakinek van vele tapasztalata, hogy hogyan lehelhető életre debianon, azt megköszönném.

Azonban ez a cockroach! Letöltöm, elindítom, megy. Második node hozzálinkel, megy. Leírás alapján, 3 parancs, 5 perc, és működik a cluster! Döbbenetesen jó!
Nagyon köszönöm!

Áááááá!!!! a leírása alapján ez "csótány" pont az, amiről régóta álmodozom. :D

Azért semmi sem tökéletes. 2 node esetén sikerült E170516 hibát előállítanom, és nem áll vissza a cluster. Úgy tűnik, másnak is adódott ilyen problémája.
Ráadásul, amikor az egyik node áll, a másik sem használható. Lehet, 3 node esetén rendben menne.

Öööö... az ugye megvan, hogy 2 node esetén nem hibatűrő a rendszered? Azaz ha 2 node-od van, akkor a működéshez 2 üzemképes node kell, különben nincs meg a szavazatok >fele. Ha az egyiket leállítod, akkor a másik sem tud írni, sőt, valószínűleg olvasni sem tudsz belőle. Ez a konkrét megvalósítástól független elméleti korlát.

Sajnos azóta már 3 node-dal is megpróbáltam, és ugyanaz a helyzet. Ha az egyiket kiölöm, a többi úgy fagy meg, mint annak a rendje és módja.
Hogy ez mennyire elméleti határ, azt nem tudom, mivel a mysql master-master replikációja 2 node-dal is megy, és ha az egyik meghal, a másikkal vígan tudsz dolgozni. Annak csak a stabilitásával volt bajom, az elméletével nem.

Kíváncsi lettem erre a cockroach cuccra - már csak a neve miatt is rokonszenves :D
Megnézem h nálam is elpukkan-e.
A hivatkozott bugreport valami régesrégi CPU-n történt, ha jól értem.

--
Gábriel Ákos

Ha megvan az eredmény, örömmel várjuk :)


// Happy debugging, suckers
#define true (rand() > 10)

Az az eleje. A végén van a párbeszédnek egy új jelentés, az szerintem független az előzőtől, és 14 napos.
Közben én is küzdök vele, és lehet, hogy a 3 node-os változat azért hasalt el nálam, mert már a 3 node sem áll fel. 2 esetében gyönyörűen szinkronizál, de ha a harmadikat csatlakoztatom, a 3. node már nem csatlakozik a clusterhez.
Érdekes módon olyan titkok is kiderültek, hogy bár a leírás szerint cockroach --host paraméterében kell megadni az IP címet, amint több szerveres telepítést mutat be, ez a --host átváltozik --adversite-host paraméterré. De sajnos ezzel sem áll fel a 3 node-os cluster. A webes felület jelzi, hogy van 3 node, a node már elterminál, mindenféle csúf hibaüzenettel.
Úgy tűnik, összességében ez is a tidb állapotában van: itt-ott működik, de még stabil környezetet nem lehet rábízni. :(

Na meg par kor, es rajossz, ha mukodo multi master db-t szeretnel, akkor el kell felejtened a relacios adatbazisokat ;)

-
Go konkurencia kezelés gyorstalpaló

Hogy Hofit idézzem: "de akkor legalább ne mondaná"

Nem tudok sokat a cockroach-ról de kapásból azzal kezdi, hogy ennek az sql csak egy felület, belül amúgy key-value store.
Szóval ennyiből akár jó is lehetne. Kiderül hamarosan...
--
Gábriel Ákos

Ha az egyiket kiölöm, a többi úgy fagy meg, mint annak a rendje és módja.

Hát ez mindenképpen érdekes, a leírás alapján ezt inkább tekintem bugnak. Nyilván van valami comm timeout, annak leteltével az elhalt node-ot ki kell rúgják a clusterből, és mindennek mennie kell tovább. Addig nyilván áll minden, és várják, hogy válaszoljon az eltűnt node.

és ha az egyik meghal, a másikkal vígan tudsz dolgozni.

Ja, és arra gondoltál-e, hogy mi van, ha a két node közötti hálózatot elnyírod? Mindkettő megy tovább? És ha ezek után divergáló változtatásokat tolsz beléjük külön-külön (amik egyszerre nem létezhetnek egy adatbázisban), akkor hogy a kénköves francba lesz abból valaha még egy adatbázis adatvesztés nélkül?

A konzisztens működés feltétele, hogy csak egyetlen jó állapot létezhet, ergó a rendszer <=50%-a elméletileg sem lehet működésképes, mindenképpen quorum kell a változtatásokhoz.

Teljesen igazad van, nem gondoltam arra az esetre, ha csak a kapcsolatuk hal el. Bár divergáló változások esetén ha helyreáll a rendszered, akkor az egyik változtatásnak meg kell szűnnie. Az ő szemszögéből nézve így is adatvesztés keletkezik. Összességében tehát nem tudom, mit nyerünk azzal, ha 3 node-ból demokratikusan döntjük el, melyik adat vesszen, mintha kettőből véletlenszerűen, vagy előredefiniáltan.

Jaj.
Szerintem kezdd ezzel, hatha:
https://raft.github.io/

érdemes lenne egy kicsit olvasgatnod a clustering elméletéről.

Egyébként épp arról van szó, hogy mivel szavaznak, ezért nem veszik el adat, mert a leszakadó node is tudni fogja, hogy ő most szopóágon van. Természetesen, a user aki arra próbált írni, az majd kap egy errort az arcába, és szomorú lesz. De ez azt jelenti, hogy a hiba ott jelentkezik, nem pedig majd neked kell a végén megpróbálni összeokoskodni két conflicting halom felett, hogy mi az isten legyen. A tapasztalat ugyanis az, hogy ez nem igazán szokott sikerülni :) És user akkor is szomorú lesz, ha az egyszer már visszaigazolt tranzakciója mégiscsak eltűnik a devnullban.

Természetesen van, amikor ez nem igazán para, de látni kell, hogy az nem azért van, mert jó úgy a cluster, hanem azért mert ott az adat nem igazán volt fontos. :)

Ebben az esetben ez nekem nem is használható megoldás, bár tényleg így korrekt.
Mivel minimális értékű módosítások és stabil konfigurációs adatok tárolódnak az adatbázisomban, úgy egy-egy módosítás elvesztése nekem sokkal jobb, mint egy elérhető szerver üzemképtelensége.
Így legalább egyértelműen kiderült, hogy nekem nem jó megoldás a stabil adatbázis cluster.
Köszönöm.

szerintem kezdj el nézelődni a config management megoldások környékén. puppet, ansible, salt, akármi. Esetleg, ha tényleg csak konfigot akarsz tartani, akkor pl etcd (+ confd). Vagy tényleg valami random nosql, ahol ez sokkal egyszerűbb. Egy olyan toollal és egy olyan problématérrel szívatod magad, ami téged nem érint, űrhajóval akarsz menni a sarki boltba tejért kenyérért. Vagy valóban használsz (és kellenek) több lépéses tranzakciók, meg random relációk?

Alapvetően konfigolni szeretnék, de távolról valós időben módosíthatón. Eddig erre két megoldásom volt:
1 - ssh-n keresztül konfigurációs parancsok futtatása
2 - adatbázis alapján konfigurálható rendszerek esetén adatbázis módosítása.
Ez utóbbi nagyságrendekkel egyszerűbb és gyorsabb, ezért keresgéltem az adatbázisok irányában. Belenéztem a config management programokba, de úgy tűnik, ezek ugyanúgy parancsokat hajtanak végre a szervereken, tehát lassabbak lesznek. Ráadásul, még ha azt is nekem kell kezelnem, hogy a módosítások sikeresen lezajlottak-e, akkor ez további bonyodalom.
Egyelőre az adatbázis még mindig egyszerűbbnek és gyorsabbnak tűnik, persze azzal a megkötéssel, hogy ez egy olyan rendszer, ami SQL lekéréssel hozzá tud jutni a konfigurációjához.
Most arra jutottam, hogy az írásra kerülő adatokat külön adatbázisba teszem, és egyedileg szinkronizálom, mivel ezek elvesztése a legkisebb kár. A konfigurációt pedig slave adatbázisokban tárolom csak olvasási joggal, így elég a master adatbázisba írnom.

igazad lehet, valoszinuleg a milliok altal hasznalt, es fejlesztett, erre a celra kitalalt es tesztelt konfigmenedzsment alkalmazasoknal valoban sokkal erdemesebb lehet egy sajat csiribiri rendszert csinalni. Biztos vannak dolgok, amiket jobban csinalsz, mint azok, akik ezzel foglalkoznak mindig.

Kérdés, hogy mennyire valós idő az a valós idő, a config management cuccok valóban általában pár perc lauffal működnek (ami bele szokott férni), viszont az összes ilyen "meg kell néznem hogy tényleg..." izét megoldják. Tipikusan úgy működnek, hogy amíg látszik a kezelt node, addig kikényszerítik, hogy az legyen a konfig, ami nekik szerintük kell. Ha elbabrálták visszateszik.

Az elosztott konfig adatbázis szintén járható út, ha olyan az appod, itt viszont az SQL a bazi nagy overhead. És szinte biztos vagyok benne, hogy nincs rá szükséged, mert valami SELECT * from config where node = énvagyok típusú tök atomi izék vannak, tipikusan key-value párok a konfigok. Erre egy bármilyen lightweightebb adatbázis jobb megoldást ad, mert lesz robosztusan működö szinkron.

Egyébként csatlakoznék kollégához: most, hogy elkezdtél gondolkodni, rájöttél, hogy tulajdonképp elég egy írható db. Még pár (tíz / száz) iteráció, és végiggondolsz mindent, ami egy konfig management eszközhöz kell :) Szóval inkább ismerkedj ezekkel, mert jók szoktak lenni. Vagy ha nem, akkor mesélj már egy kicsit bővebben arról, hogy tulajdonképpen mit akarsz megoldani, milyen elvárások és constraintek mellett (pl azért ragaszkodunk-e az sqlhez, mert szög-kalapács, vagy azért, mert a végén a programnak mindenféleképp abban kell a konfigja)

Az egyik ilyen rendszer egy egyszerű e-mail szerver, ahol elvárás, hogy a jelszó módosítás például azonnal életbe lépjen. Értem én, hogy egy config management tök kiforrott, és globális megoldást ad, de mindezek a problémák sql alapon fel sem merülnek.
Valós életből származik a tapasztalás, hogy konfigurációs fájlok matatásával egy módosítás 5 másodperc, adatbázis konfiggal fél másodperc.
Ez utóbbi a felhasználók számára sokkal kényelmesebb.
Az sql ugyan lassabban éri el az adatokat, cserébe a szerverek újraindítása nélkül, mindig a valós idejű adatokhoz fér hozzá. Ha jól tudom, még cdb esetén is szükség van a reload parancsra, hogy újraolvassa azt.
Ráadásul a valós e-mail szerver esetén messze nem a konfigurációs adatbázis olvasása viszi el az erőforrásokat zömét, tehát nem tudom, mennyire lényeges ezt a sebességet tuningolni.
Talán LDAP-on keresztül lehetne még hasonlóan konfigurálni, de abban semmi tapasztalatom egyelőre.
Tehát én nem látom ördögtől elrugaszkodottnak az adatbázis megtartását.

Tenyleg jo lenne ha felvazolnad inkabb kompletten mit szeretnel, legalabbis a user adatok nagyon nem ugyanaz mint a konfigok.
Az hogy felhasznaloi adatokat tarold sql-ben, ldap-ban vagy egyeb modon jelentosen elter attol minthogy egy service configot tarolj ilyenben.

Konfigurációs adatok alatt értettem az alkalmazás konfigurációjának azon részét, ami változhat.
Egy webszerver, névszerver vagy levelezőszerver esetén is a konfigurációk gyakran vegyesen tárolják a szolgáltatás és a felhasználók adatai.
Pontosítok tehát:
Az alkalmazásom esetén a konfiguráció egy része fájlokban fixen tárolódik, és telepítéskor kerül az alkalmazással együtt a rendszerbe. Ezek szinkronizálása nem szükséges.
Másik része dinamikusan kerül tárolásra, jelenleg sql adatbázisban. Ezek nevezhetőek user adatoknak is. Én pongyolán konfigurációs adatoknak hívtam ezeket, elnézést a félrevezető megfogalmazásért. Ezen adatok lehető legnagyobb biztonságát kell elérnem.
Ha jól értelmezem a visszajelzéseket, akkor a pontosított feladatra egy Mysql Master-Slave replikáció jó megoldás, de az én fogalomrendszerem hiányosságai pótlásra szorulnak.

Igy mar vilagosabb, szoval azokra az adatokra gondolsz aminek modositasahoz (legtobb szolgaltatas eseteben) nem kell szolgaltatast ujrainditani, mert azok nem a service config adatai.
Arra, hogy peldaul levelezesnel felhasznalok es fiokok adatait tarold elegendo igen egy mysql cluster vagy lehetne ldap is, csak azt irtad nem ismered.
Megfeleloen konfiguralva mysql master-slave jo lehet erre, csak az nem tiszta szamomra hogy tekintesz arra az adatbazis clusterra, azert kell hogy HA meglegyen es ha megallna a master akkor slave-rol mukodjon tovabb a levelezes vagy csak azert hogy ha gond lenne masterral akkor te kezzel belenyulsz hogy hasznalja masodlagod szervert, netan csak ha adatvesztes lenne akkor slave mint backup funkcionaljon? Avagy valami elosztott megoldasnak kellene, hogy mindkettot hasznalnad egyidejuleg (ez esetben irasra is vagy csak olvasasra lenne masodik gep)?

Ennyi okosodás után, amit itt a témában összeolvastam, most azt gondolom, a szerverek írni minden adatot helyileg írnának, és ezek nem kerülnek replikálásra. Hiba esetén ezek az adatok elvesznek, de nem kritikusak. Ilyen adatok például, számlálók értékei, vagy a helyi statisztikai adatbázisok adatai.
Amúgy minden fontos konfigurációs adat csak a master adatbázisba kerül beírása, ahonnan a slave-ekre replikálódik. Onnan a szerverek csak olvassák az adatokat.
Egy szolgáltató node kiesése esetén a többi node gond nélkül szolgáltat.
Ha csak a kapcsolat szakad meg a master és slave node között, akkor is az utolsó adatokkal az elszakított node tovább képes szolgáltatni.
Ha a master döglik meg, akkor is minden slave az utolsó állapot szerint tud szolgáltatni. Ilyenkor a master életrelehelése után az vagy automatán tovább tudja küldeni az adatoka a slave-ek felé, vagy itt már kézzel kell újra replikálni. Ez már nem kritikus, mivel itt úgyis van egy kézi beavatkozás.
A lényeg, hogy bármelyik pont hibája esetén üzemel a szolgáltatás.

Hátizé, ha az 5 sec egy jelszócserénél sok, akkor rosszul fogod :) El nem tudom képzelni, ez hol ne lenne elfogadható. Ráadásul, ha úgy managelsz usereket, hogy nincs központi helyen, hanem tologatod le a usereket localba, akkor (jó eséllyel) rosszul fogod :) Ja, és a userek és azok passwordje az nem igazán konfiguráció. Az az alkalmazás adata, amit az ő dolga kezelni.

Nem, nem elrugaszkodott megtartani az adatbázist, csak látnod kell, hogy míg az sql esetén fel se merül, hogy ne legyen gyors, addig viszont az felmerül, hogy a te gondolataid az adatszinkronizácónál viszont igenis felmerülnek (mint azt te is láttad). Szóval ki kéne találnod, hogy mik is a fontos elvárásaid.

Nem volt szó arról, hogy melyik adat hány példányban és hol tárolódik, csak arról, hogy hogyan kerül ez a kiszolgáló rendszerbe konfigurálásra.
Lehet alapjaiban új rendszert is kiépíteni mindig, de igyekszem egy létezőbe integrálódni, ahol egy módosítás után gyakran ellenőrzik le, sikeres volt-e az új beállítás. Itt pedig - jelenleg, és lehet eléggé elítélhetően -, de jelez a user számára, hogy használhatja az új konfigurációt. Ha itt fél másodpercet kell várnia a user-nek vagy 5-öt, azt ő különbségnek érzi. Én meg megtaníthatom rá, hogy nincs igaza, pedig az van neki. Én szeretném elérni, hogy fél másodperc legyen, ha lehet annyi.

hogy a jelszó módosítás például azonnal életbe lépjen.

Namost ezek az opciók vannak:
- elfogadható, hogy nincs rendelkezésre állás, ha partícionálódik a hálózatod (megoldás: központi jelszóadatbázis, onnan authentikálunk, ha nem elérhető a hálózat miatt, akkor nincs szolgáltatás),
- ha partícionálódik a hálózatod, akkor nem baj, ha nem aktuális a jelszóadatbázis, de inkább legyen rendelkezésre állás (megoldás: aszinkron replika, pl. LDAP/SQL/akármi alapon),
- nem fogadható el sem a nem aktuális jelszóadatbázis, sem a rendelkezésre állás csökkenése (megoldás: meg kell akadályozni a partícionálódást: egy szál szorosan csatolt data centerbe kell mindent telepíteni, atomredundáns hálózattal). (gyk: ez tulajdonképpen a "dögöljön meg a szomszéd tehene is" elv érvényesítése: ne halhasson meg a fél hálózat, csak úgy, ha meghal az egész)

Válassz!

Mondtam ugye, hogy git.
--
Gábriel Ákos

ja igen, azt ki is hagytam, hogy vagy csak csapd bele egy git repoba :)

MS SQL server. Elegge kiforrott.

A szerverrel nekem sincs bajom, bár valós terhelés alatt, azért tapasztaltam már meglepő tulajdonságokat. Mindezek ellenére, szerintem arra, amire szánták, arra jó.
Nekem csak a replikálása tér el az igényeimtől. Terheléselosztásra jó, de az adatbiztonság eléréséhez nem.

(Hopp ... ezt elnéztem ... MS != MY sorry ... M$ világban nem vagyok jó, lehet, hogy az jó.)

Nincs vele kevesebb szívás, mint a MySQL-lel. Sőt.. sőt.

Magas rendelkezésre állásban, vagy mire gondolsz?

Egyrészt konfigurálásban. Belefutottunk abba, hogy a HA klaszterben létrehozol egy felhasználót, az ugye minden node-on létre lesz hozva. Viszont a felhasználók GUID-ja különböző lesz, így a failover bukta. Kézzel kell a megfelelő GUID-dal létrehozni a felhasználókat és aztán jó lesz.

Másik izgalom akkor volt, mikor nem futott le az adott táblán egy egyszerű SELECT. Néhány százezer rekordot tartalmazott a tábla, viszont a rekordoknak van olyan mezője, amiben olyan 300KByte-nyi TEXT adat volt. Sehogy nem akart lefutni a SELECT, majd kiderült, hogy sok volt az adat számára a táblában. Elkezdtük törölgetni a rekordokat és jó lett.

Volt még olyan helyzet, mikor leszakadt az egyik node. Mikor visszatalált, megjött a performance drop, mert elkezdte lelkesen ledolgozni a lemaradását. Csak mi dolgoztunk volna a rendszeren.. :)

"Kézzel kell a megfelelő GUID" , vagy SSSD-t kell haznalni

-
Go konkurencia kezelés gyorstalpaló

Ahogy kiveszem a leirasodbol, neked SQL alapu adatbaziskezelore van szukseged, de az sql meg nem feltetlen jelenti azt, hogy relacios adabazis kell ala (ezt te tudod). Azert mondom, mert SQL-t tudo nem relacios adabazisokkal sokkal egyszerubb dolgod van, ha reprikalni szeretned oket. Azt is jo volna tudni, hogy pl csak replikat szeretnel, vagy terhelest elosztani is? Relacios adatbazisokkal altalaban csak a szivas van, vagy nincs is teljesen kiforrva a megoldas, vagy valami 3rd party reteget(ket) kell ele huznod, vagy a penztarcadba kell nyulni. Azt is jo volna specifikalni, hogy mekkora latency fer bele, nagyban befolyasolja a valsztott megoldast. 0 (sync), vagy x (async)?

-
Go konkurencia kezelés gyorstalpaló

Szeva,

Holnap pont errol tartok egy prezentaciot hogy valosithato meg ez MySQL alapokon, ha erdekel irj privatban es elkuldom hol lesz (nem akarok relytett hirdetest csinalni itt.)

De roviden mind MySQL replkacioval is elerheto a High Availability (HA) de nem grantalhato, hogy nem lesz data loss ha csak par tranzakcio de akkor is. Ennek eselye minimalizalhato semi-sync replikacioval de meg ez sem nyujt 100% garanciat.

A jelenleg piacon levo megoldasok kozul az egyik legkiforrottab a Galera ami MySQL alapokon sync cluster megoldast biztosit. Itt crash eseten sincs data loss es garantalja a data consitencyt de ennek is ugyan ugy megvannak a limitjei es nem minden workloadra jo.

De ha jol ertem nagyreszt static adatokat tarolnatok (konfiguracios adatok), erre egy jol beallitott Master-Slave(s) replicaset is megfelelo lenne, de persze egy cluster is ugyan ugy mukodhet. Ha van meg kerdesed ird meg nyugodtan.

Rögzítitek a prezentációt? Ha igen, akkor engem is érdekelne. :)

Sajnos nem lesz felvetel, de az eloadas ingyenes meetupon megtalalolhato.

Ezt az, amit itt is reklámoznak, s fél kettő felé kezd?
Ha nem, egy pmet dobsz, pls! Ty!
--
blogom

Köszi! Sajnos az előadásodról - legyen bárhol is - lemaradok, mivel csak most olvastam a bejegyzésed, és az időm is le van kötve.
Az adatbázis egy levelezőszerver konfigurációját tárolná. Egyrészt az account adatok, másrészt a forgalmi adatok egy része kerülne bele. Mivel a levelezőrendszer redundáns, több gépen képes párhuzamos működésre, ha a konfigurációját is szinkronban tudnám tartani, egy elég stabil, megbízható rendszert kapnék. Ehhez persze stabil master-master replikáció kell. Az adatbáziskezelőtől nem várom el relációk kezelését, de az adatszerkezet azért tárol azonosító kulcsokat, a táblákban tárolt adatok közötti kapcsolatok kezelésére.
Az eddigi tanácsok alapján én is a Galerát és a Tidb-t látom egyelőre esélyes implementációnak.
A pure master-master mysql replikációra nem mernék építeni.

Amit irsz, arra talaltak ki a shared/distributed nosql adatbazisokat. Egyszeru query-k, elosztott, megbizhato mukodes.

A SQL soha nem lesz megbizhatoan es gyorsan multi-master, a tranzakcios lockok miatt.

"A SQL soha nem lesz megbizhatoan es gyorsan multi-master" Az SQL az egy nyelv, semmi koze a multi-masterhez ;) De abban egyetertunk, hogy valami elosztott nosql nyavaja is valoszinuleg megfelel a celnak, plusz az "SQL on NoSQL" a meno manapsag ugyis, sok NoSQL adatbazisnak van valami SQL interface.

-
Go konkurencia kezelés gyorstalpaló

"tranzakcios lockok miatt"

Ezt lerinad kicsit bovebben?

Kepzeld el, hogy ugye sql-ed van, szoval frankon szopsz az ER-diagrammokkal ahelyett, hogy szepen egy json faba tudnad pakolni az adatokat.

Amikor egy tranzakciot inditasz, ami tobb tablat is modosit (n:m kapcsolo tablak pl.), akkor az adatbaziskezelonek 2 lehetosege van:

- row-level lock-ot tesz a modositott rekordokra, es ha egy masik tranzakcio hozza akar ferni, megvarja, amig a tied befejezodik.

- MVCC-t csinal, es remeli, hogy nem fog utkozni.

Az elso esetben _minden_egyes_kurva_sor_modositasara, olvasasara egy cluster-wide lock-ot kell elhelyezni, hogy az osszes tobbi master is tudja, hogy ez most valtozik. Performance -> 0.

A masodik esetben (amit manapsag probalnak tolni a sql-gyartok, mert jol elfedi a hibat a sql design-jaban) esetben barmelyik commit() dobhat hibat. Namost nemtom, te mit lattal, de en nem, vagy alig-alig lattam programozot, aki a commit()-ra hibakezelest, ne adj' isten, retry()-t rakott volna. Mert a retry ugye bonyi.

Ebbol kovetkezik, hogy a tranzakcios adatbaziskezelok SOHA nem fognak skalazodni multi-master modon. Erre csak a document storage es egyeb nosql-ek kepesek, ahol kapasbol egy osszetett dokumentumod van, es azt garantalja, hogy atomic modon update-eli. Na ezt jol megmondtam.

En konkretan le is szalltam a SQL-rol mar par eve, es mongodb-t tolok. Eddig nem volt vele baj, es a sokal hulye DDL es a tobbi marhasagot is frankon el lehet felejteni. A hibernate-rol meg ORM-rol nem is beszelve. El nem hinned, mennyivel egyszerubb az elet igy.

Nem teljesen igaz amit irsz. Ez a kulonbseg a pessimistic es az optimistic locking kozt. A cluster megoldasok optimistic lockot hasznalnak es ez nem jelenti azt hogy trx1 a node1-on lockolni fogja a tobbi szerveren is a tablakat.
Itt van kent link ami ezt jol leirja:
- https://en.wikipedia.org/wiki/Optimistic_concurrency_control
- http://galeracluster.com/documentation-webpages/certificationbasedreplication.html

Nana. Csakhogy a commit() eseten failure nem annyira szokasos a sql-t hasznalo programozok kozott. Aztan ha kozben meg kikuldte a raktarba a megrendelest, es nem sikerult a commit, akkor meg vakarja a fejet.

Ha kellokepp hulye volt az ER designere, akkor meg frankon lesz par 'hot spot' a tablaszerkezetben, ahol folyton utkozesek lesznek, mert minden azokat modositja.

Akkor meg ott van sql-nel, hogy attol fuggoen, hogyan shard-ol, ossze kell fesulni tobb shard-rol az adatokat. Mert ugye 1 table nagyon limitalt szerkezetu, sok-sok kell belole, ettol lesz nehez a sharding.

Nem mondom, lehet sql master-mastert csinalni, de olyan ganyos limitacioi lesznek (mar az osi, single-node sql szerverekhez kepest), hogy sokkal jobban jar mindenki egy egyszerubb, direkt multinode mukodesre tervezett nosql-el.

Na de. Az mar regen rossz, amikor az egy szempont az adatbazissal szemben allitott kovetelmenyek kozott, hogy hulyek is fogjak hasznalni :D A hulye az hulye marad akkor is ha nem tranzakcionalis adatbazisra fejleszt. Attol nem lesz okosabb, meg korultekintobb.

-
Go konkurencia kezelés gyorstalpaló

Nem, csak amikor nosql vs. sql hasonlitgatas megy, akkor ez fontos szempont. Ugyanis a multi-master sql mar nem az a sql, amit sokan ismernek, ha van is, annyi megkotessel, hogy inkabb egy sql v0.3 -nak nevezheto.

Ebben tovabbra sem ertek egyet veled. Termeszetesen minden problemara a megfelelo alkalmazast kell hasznalni. Es az a hozzaallas hogy "Aztan ha kozben meg kikuldte a raktarba a megrendelest, es nem sikerult a commit, akkor meg vakarja a fejet." ez mindenhol elfogadhatatlan NoSQL vagy SQL legyen, ha valaki olyan alkalmazast fejleszt ami nem kapjal el a hibakat ha pl egy commit nem sikerul az inkabb menjen el havat lapatolni...

Tehat hulye alkalmaz vagy hulye design stb... az barmilyen rendszeren bajokat tud okozni. Tehat nem ebbol kell kiindulni.
Jelenleg leteznek MySQL-re megbizhato cluster megoldasok melyek szeles korben banki rendszerekben is hasznalatosak, es ott az adatvesztes teljes mertekben elfogadhatatlan.

A sharding az megint egy teljesen mas tema, a topic indito nem is errol kerdezett. De amugy mar erre is letezik megoldas ami nagyon is jol mukodik es egyszeru kezelni.
https://www.percona.com/blog/2016/08/30/mysql-sharding-with-proxysql/

Neked is azt tudom mondani, hogy igen, megoldhato a sharding is sql-el, de annyira bonyi es olyan sok megkotessel jar, hogy az mar nem az a sql, amit az emberek sql-nek ismernek. Es egy multi-master sql rendszernel mind teljesitmenyben, mint skalazhatosagban, es legfokepp, mint bonyolultsagban jobb egy nosql.

De itt mar a 'jo az a dbase3+ dos alatt, csak kar, hogy nem lehet pentium mmx alaplapot kapni' - fele threadbe megyunk. Igen, dbase3+ igazabol mai napig jo rengeteg mindenre. Csak arra nem, amerre az innovacio mainstream-je halad. Ergo hatramarad, akarcsak a sql alapu dbms-ek.

Most belekukkantottam a percona xtradb cluster limitations-be. A commit failure-on kivul meg ott van, hogy:

The write throughput of the whole cluster is limited by weakest node. If one node becomes slow, the whole cluster slows down. If you have requirements for stable high performance, then it should be supported by corresponding hardware.

Tehat ez csak master-master replikacio, nem sharding. Rohej.
- osszes adat megvan osszes szerveren -> DB meret nem tobbszorozodik
- osszes iras megvan az osszes szerveren -> irasok nem elosztottak
- bevarjak egymast a szerverek iraskor -> irasok mindig a leglassabb szerverhez igazodnak

akkor itt most igazabol mit is nyersz? Azt az idot, ami a sql query parse + execute lenne, elveszted viszont azt az idot, ami az osszes megvaltozott rekord replika log irasara + teritesere megy, es bejon melle sok-sok egyeb hatrany hirtelen.

Ilyen aprosagok, hogy 1 node lehal vagy esetleg split brain, nem is emlitem - ugye tobb node visszaallitasa tobb ido is.

Na, ezek miatt mondom, hogy multi-master sql-nel sokkal jobb egy tisztesseges nosql, mert nem realis alternativa.

Ez olyan, mint a DRBD C-protokol, akkor kapod meg, hogy kész, amikor az összes node végzett. A multi-masterért a performance a fizetség.
Viszont quorum fenntartásával a split brain nem létezik galeránál, valamint az ACID paraméterei megmaradnak a DB-nek. Van ahol ez utóbbi elég fontos, mondjuk senki sem szeretné, ha az épp magkapott fiezése a következő queryben nem látsza még.

Tovabbra is kerdes, hogy tenylegesen mit nyersz multi-masterrel ez esetben. Merthogy sokat vesztesz, az biztos.

Rendelkezésre állást, valódi ACID tulajdonságú relációs adatbázissal.

Soha senki nem allitotta hogy ez egy sharding megoldas, sot ki is emeltem h nem az. Szal teljesen felelslege ahoz hasonlitanod.

Ez a proxysql nyeritesre kesztetett. Ha most figyelmesen megnezed, ha valaki ezt probalja 0-rol hasznalni, mi kell hozza:
- sql
- mysql ddl
- mysql admin
- proxysql admin
- cluster design es generalisan az egesz architektura megertese

Ennyibol mar megvan egy komplett mongodb 101 for java developers kurzus, tobbszorosen is.
Ez a bohockodas a query atirassal kesz. Roppant robusztus rendszer lesz ez igy, remelem, egyszer kap egy ilyet karbantartani az, aki kitalalta vagy bevezette.

mongodb kapasbol tud sharding-ot es aggregate query-ket rajtuk, meg csak nem is bonyi es relativ szepen integralva van bele. konkretan a developer course-ban feladat is elinditani egy 3 shard/3 replika mindegyikben clustert, annyira egyszeru. Egy 10 perces videoban csinaljak, erdemes megkukkantani.

ertem en hogy szereted a mongodb-t, szerintem is meg van a helye, de azert legy szives hasonlits ossze ACID menten egy mysql-t mongodb-vel.
eleg sok helyen megremegnek amikor meghalljak a BASE mozaikszavat.

En sem hasonlitanam MySQL-t ossze MongoDB-vel mind a ketto remek alkalmazas es megvan a maga hasznalati terulete. Minden problemara a megfelelo tult kell hasznalni.

Melyik bankoknal hasznalnak ilyet? mert akkor azt inkabb elkerulom. :)

ide is egy sub!

ilyen nekem is jól jönne. most az egyik program postgresql-t használ postgis-szel, postgis szükséges, és a postgresql hot standby funkcióját használja, ami nekem egyáltalán nem tetszik, nehézkes. na e helyett kellene valami master-master replikáció, bármelyik node-on bármit csinálok, szórja az igét a többinek.


"I'd rather be hated for who I am, than loved for who I am not."

Erre egy jo megoldas lehet https://www.percona.com/doc/percona-xtradb-cluster/LATEST/index.html
Neked is azt mondom, h pont ilyenrol tartok eloadast holna, ha erdekel irj egy privit.

https://hup.hu/node/153195

Gondolom errol van szo.

köszi, lehet jó, de "solution for MySQL". ide postgresql+postgis kell, azt használja a program és a programot nem itt írják, módosítani ezen nem tudok.


"I'd rather be hated for who I am, than loved for who I am not."

postgresql szerintem elég jó ebben a témában bár tapasztalatom a master-slave felállással van (és az se sok)
ami viszont brutálisan jó cluster az az elastic. szerintem kb. mindent kibír. ez mondjuk NoSQL, de a feladatra amit leírtál pont nagyszerűen alkalmas.

--
Gábriel Ákos

Ha az elasticsearch-re gondolsz, az nagyon messze van (még) attól, hogy mindent kibírjon. :)

Igen, arra gondolok. Pontosítok: én még nem tapasztaltam adatvesztést, amit nálam/nálunk ki kellett bírni azt kibírta.
--
Gábriel Ákos

nem tapasztaltal, vagy nem volt? :)
sajnos komoly a kerdesem, tapasztalatbol irom.
egyebkent en is alapvetoen kedvelem az elasticsearch-t, de pl. penzugyi adatokat nem biznek ra.

Kozben egy masik szalon kiderult, hogy configokat szeretne benne tarolni, az elastic pedig egy "search and analytics engine". En eloszor hbase-t mondtam volna hive vagy phoenix sql enginnel, de asszem az overkill lett volna :D De valoszinuleg egy mezei Cassandra tokeletesen eleg volna a problemara. Tud elosztottan tarolni, tamogat valami sql-t (vagy afelet), es bizonyos szintig lehet benne kapcsolatokat is kezelni.

-
Go konkurencia kezelés gyorstalpaló

etcd

Erre kábé az SQL az overkill, minden más ésszerűbb.

Felteteleztem, hogy oka van, de velemenyem szerint ez a feladat nincs kelloen specifikalva. Amig nem tudjuk a pontos kovetelmenyeket, latency, terheles, hany node, melyik sql szabvany, iras vagy olvasas intenziv, kell-e multi datacenter/availability zone, akarnak-e fizetni, sync/async, kellenek-e relaciok, mekkora a merete az adatbazisnak (tabla, oszlop, sor szam), kell-e loadbalancer vagy csak hot backup (tudom ezek egy resze mar kiderult itt-ott). Ingyen ennyi preferenciat mondok :D a tobbi fizetos ;) Szoval addig csak a levegobe lovoldozunk. Persze az is lehet, hogy csak egy mezei master-master sql-re van szukseg :)

-
Go konkurencia kezelés gyorstalpaló

Csak két node, két külön adatközpont. Egy levelezőszerver konfigjait tároló adatbázis.

Akkor neked tenyleg etcd vagy consul kell. Igaz ezek harom noderol indulnak a RAFT miatt.

Azt mondd meg nekem miért nem jó ezt gitben tárolni?

--
Gábriel Ákos

A git nem pont erre lett kitalálva ... ha már fájlokban akarnám tárolni, akkor rsync és minden pöpec. A fájlokkal csak az a baj, hogy a konfigurálás bonyolultabb. Egy sql szervert távolról elérni és valamit módosítani sokkal gyorsabb.

Ex cathedra: "nem pont erre lett kitalálva". Ok. Nekem nem életcélom hogy megoldást adjak neked, részemről EOT.

--
Gábriel Ákos

marmint, nem arra, hogy konfig FAJLOKAT tarolj? ne viccelj mar.

Szerintem nem arra, hogy éles rendszert gittel konfigurálj. De szerencsére, aki ezt szereti, megteheti.

Pedig ha belegondolsz, valojaban verziokezeloben a legjobb teljes OS-eket tarolni. Miert:
- elosztott
- tudod, hogy mikor, ki, mit modositott
- barmikor vissza tudsz allni barmilyen allapotra
- ertesiteseket tudsz kapni modositasi esemenyekrol
- adott esetben a rendszered reszleteit meg tudod osztani masokkal (pld. read only hozzaferes adott konfiguracios fajlokhoz, vagy modositasi lehetoseg csak erre, vagy arra a konfigra)
- hookokkal tetszoleges policyt meg tudsz szabni, pld. letilthatod, hogy az sshd configjaban a rootnak jelszavas autentikaciot allitson barki (csak mondtam egy peldat, barmi lehet)
- letagadhatatlan minden modositas (nem en voltam, de, te voltal)
- ha jol megveded a VCS-t, egy betores sem okoz akkora fejfajast (integritasellenorzes, visszaallitas)
- barmikor vissza tudod nezni, hogy mikor, mit, miert csinaltal (ha koveted azt az uzemeltetoi gyakorlatot, hogy a modositasaidhoz ertelmes kommentet irsz)
- automatikus backupot kapsz az OS-eidrol/konfigjaidrol
- stb.

Mi a legtobb gepunk osszes fajljat igy kezeljuk (VCS-ben). ~12 evre visszamenoleg megvan minden modositas az osszes gep osszes fajljara (nem csak konfig, az OS is).

Csak kiváncsiságból kérdem, melyik VCS?

A datumbol es a fenti leiras reszeibol (pld. jogosultsagkezeles) nagyjabol sejtheted, hogy nem git. :)
Subversion egyebkent.

"külön adatközpont" pont emiatt biztos olyan megoldast valasztanek, amiben by default van erre megoldas, es ez a kovetelmeny kapasbol kizarja a relacios adatbazisokat, de kovezzetek meg, hogy van aki uzemeltet multi dc master-master rdbms-t.

-
Go konkurencia kezelés gyorstalpaló

milyen tavolsag van a ket DC kozott?

Ez dinamikus. De nem feltétlen egy országban vannak.

ami azt illeti, csak ugy erdemes gepeket telepiteni, ha barmikor ujra tudod deployolni az egeszet, szoval eleve a kerdesnek nincs ertelme, erre van a chef, a puppet, az ansible, a cfengine, vagy akar a saltstack, valassz egyet, ird meg benne a rendszered, az egeszet tedd fel a gitre es dolj hatra.
Ha egy szerver nem huzhato vissza 2017ben automatikusan valami konfigmenedzsment eszkozbol, az a szerver nincs bekonfiguralva.

en tovabblepnek, immutability imagebol, kell a francnak mutable infra :)

sub

Eloszor is erdemes a slaved crash-safe-nek konfiguralni: https://www.percona.com/blog/2013/09/13/enabling-crash-safe-slaves-with-mysql-5-6/ ez valoszinuleg meg is oldja a bajod.
(roviden: allitsd le a mysql-t, tedd bele a konfigba, hogy
relay_log_info_repository = TABLE
illetve
relay_log_recovery = ON) es kb. meg is oldottad a bajod. (ja, es hasznalj legalabb 5.6-os mysqlt)

Esetleg hasznalhatsz Percona XtraDB clustert, ott barmelyik node-ot irhatod, ha valamelyik node esetleg korrupt lesz, akkor kijavitja magat (de itt tudd, hogy minumum 3 gepre lesz szukseged a mukodo furthoz.)

Ha esetleg kerdesed maradna, varunk sok szeretettel a Budapest MySQL Meetupon. https://www.meetup.com/Budapest-MySQL-Meetup/