MariaDb master-slave tapasztalatok

Adatbázis: SQL, XML DB

Szeretnék egy master-slave replikációt kialakítani, de olyat, hogyha szétesik a replikáció, akkor a master leállítása nélkül lehessen azt folytatni, újraépíteni.

Úgy tűnik itteni fórumbejegyzésekből és más és saját tapasztalatokból is, hogy a mysql erre nem képes.

Azonban, azt állítják, hogy a MariaDb a saját GTID kezelésével már képes erre.

Gyakorlati tapasztalatok érdekelnének olyanoktól, akik MariaDb master-slave replikációt használnak, GTID alapon, hogy ez valóban így van-e?

Alternatívaként érdekelne még olyan módszer is, ami egy megszakadt és nem folytatható replikációt helyretesz a master LOCK-ja nélkül, bár eddig én ilyen nem találtam sehol.

( after | 2021. 10. 25., h – 11:41 )

Bár megoldást nem nagyon tudok adni, de szeretnék kitekinteni a saját buborékomból, ezért érdeklődnék a körülményekről.

Mik azok az üzleti körülmények (cégméret, piac, IT csapat méret, satöbbi) vagy igények, amiért ezt megéri vagy szükséges házon belül reszelgetni menedzselt megoldás, például RDS Aurora helyett?

3 adatbázisnál biztosan megéri. 300-nál már nem látom ezt egyértelműnek. Amúgy egyelőre a technológia érdekel inkább. Fel vagyok rá készülve, hogy a MySql/MariaDb két szerveres környezetben nem tud ilyen megbízhatóságot nyújtani. De azért szeretnék utánajárni.

Elvi akadályát nem látom egy szinkronizációs programnak, ami megszakadt szinkron esetén helyreállítaná a szinkronitást. (Természetesen, ha a slave read-only módban van.)

( blackluck v | 2021. 10. 25., h – 13:13 )

Ha csak sima 2 node-os master-slave felallasrol van szo akkor GTID nem fog sokat javitani neked.

Helyreallitashoz nezd meg percona toolkitben pt-table-checksum es pt-table-sync -et, roviden azzal tudsz annyit csinalni hogy ellenorizni tablankenti szinkront, illetve ha szinkronizalni akarod akkor masteren meglevo adatokat replace-el bekuldi modositas nelkul es igy replace utasitas lejut slave-re hogy azon is ugyanaz az adat legyen. (Ehhez nem art slave-en arra az idore skip error-okat berakni hogy ne alljon meg, illetve elotte tabla strukturat kezzel szinkronizalni ha az is elterne.)

A pt-table-sync-et megtaláltam, de sajnos az is csak lock-olt táblánál képes szinkronizálni.

Amúgy a MySql és MariaDb GTID különbéségél ezt írják a MariaDb GTID-jérő:

Emiatt reménykedtem, hogy ez a replikáció megbízhatóbb, és ezért keresek erről gyakorlati tapasztalatot.

( uid_6201 v | 2021. 10. 25., h – 15:35 )

Mariadb tartozéka a Galera. Az ilyen. Leállítom a másik node-ot, ami akár szintén master és megy tovább ez, majd ha azt ismét elindítom akkor felkapcsolódik ide és átrántja a változást.
Egyedül a mindkettő egyidejű leállása okoz manuális indítási feladatot.

No meg ha emlékezetem nem csal, akkor a galera nem master - slave, hanem master - master replikációt végez, így váltáskor nincs olyan móka, hogy a slave-t master-ré kell előléptetni, a kiesett master-t meg slave-ként visszalptetni amikor már elérhető. Galera esetén csak node kilép, node belép van.

Nem fogalmaztam pontosan. Szétesés alatt nem azt értem, hogy az egyiket leállítom, és emiatt esik szét a replikáció. Mert innen a mysql is szokta tudni folytatni. A MySql-lel az a baj, hogy ha valamilyen kapcsolati probléma miatt megszakad a replikáció, akkor néha úgy szakad meg, hogy egyáltalán nem képes folytatni.

De jól hangzik, hogyha használod a Galerát, és még nem tapasztaltál ilyen folytathatatlan szakadást. Mindenképp megnézem, köszönöm!

Nekünk 3 node-os percona xtradb van, ami Galera megoldást használ. Ott ha kiesik 2 node, akkor is vígan elvan a harmadik, de sajnos ha visszajönnek a node-ok, sem az IST (incrementált) sem az SST (teljes) 'restore' sem hajlandó értelmesen (gyorsan, stabilan) helyreállni a node-okon, így inkább xtradb-vel húzzuk újra manuálisan a teljes instanceokat.

( hory v | 2021. 10. 26., k – 15:30 )

vagy szintet lepsz ebbol az avitt sql vilagbol, es hasznalsz olyan rendszereket, amik kapasbol clusterezettek, mint pl. mongo. Kiesik egy node -> valasztas -> uj master, megy tovabb.

Galera nem oldja meg két node-dal, páratlan számú kell a quorum miatt. Igaz, harmadiknak elég egy garbd is valahova.

Meg az nem is master-slave, hanem multi-master (azaz bármelyikre írhatsz). Bár jobb, ha csak egyet használsz írásra.