MySQL Master Master replikáció hiba

Adatbázis: SQL, XML DB

Sziasztok

Abban kérném a segítségeteket (elfogyott az összes ötletem), hogy készítettem ez alapján a leírás alapján Link egy MASTER MASTER replikációt.

A replikáció látszólag működik (az adatbázisokat át szinkronizálja), de a MASTER1 és a MASTER2 Read_Master_Log_Pos: paramétere elkezd eltérni.
Ez a hiba akkor jött elő amikor hibás query futott le a MASTER1-en.

A rendszer alapja egy Debian 9, a MySQL verziója 5.7

Előre is köszönöm a segítséget.

Ha kell akkor egyéb infókat is tudok írni.

( banyek | 2019. 05. 27., h – 13:37 )

folyamatosan irod mind a ket db-t?
Mit ertesz az alatt, hogy a Read_Master_log_Pos: parametere elkezd elterni? Azoknak nem is kene egyformanak lennie mind a ket szerver a sajat binlogjat irja, Ha a MASTER1 "show master status\G" es a MASTER2 "Read_Master_Log_Pos" megegyezik (es vica-versa) akkor nincs gondod.

( plt | 2019. 05. 28., k – 07:45 )

Ha egy hibatűrő adatbázis clusterbe elméletileg is minimum 3 node kell, akkor egy ilyen két gépes master-master replikáció mennyire lehet megbízható?

Hibás query esetén evidencia, hogy a replikáció lepihen és várja az interakciót az okosabbtól.
Elég nagy baj lenne, hogy ha egy hibára futó lekérés esetén csak úgy folytatná a replikációt.

A hibára futó query alapján járj utána mi okozta a hibát és az alapján haladj tovább az
adatbázis integritásának ellenőrzésében...merthogy lehet eltérés van a kettő közt!

Na, ha ez tortent, akkor az a helyzet, hogy az egyik szerveren lefutott egy query ami a masik szerveren nem tudott lefutni, pl. olyan sort update/torolt-elt, ami ott nem talaltato meg, vagy valami hasonlo. Erdemes megnezni, hogy mi volt a query ami a gondot okozta (latni fogod a tabla nevet, illetve magat a query-t)
Ha latod, hogy mi volt a query ami a gondot okozta, akkor latod, hogy melyik tablat probalta valtoztatni, es mi volt a parancs ami nem tudott lefutni. Osszehasonlithatod a tablak tartalmat, stb.
Ha csak esz nelkul atskippeled a hibas queryket, akkor a ket adatbazisod elmaszik egymastol, es onnantol kezdve kesz a baj.

Javaslom ellenorizd egyben a ket szerver verziojat es konfigjait, hogy szinkronban vannak-e.
Hatha olyan miatt jott elo a problema, replika oldalon hogy nem ugyanaz a 2 szerverben a default karakterkodolas vagy kissebb a tarhely benne es a generalt tmp tabla nem fert el rajta vagy valami hasonlo okra vezetehto vissza a hiba.

( Sixday v | 2019. 05. 28., k – 19:00 )

Ezt az egeszet dobd ki a kukaba, tanulni jo volt, de ha mysql cluster akkor galera vagy percona

sot egybol vegyen a gepbe 256GB ramot, 40G-s halozatot, 13 nodedal!!!444
egy kisebb forgalmu site ala nehany megkotesekkel boven jo a mm cucc

hogy ontopic is legyek az opnak: az mm az tulkepp ket szembeforditott master-slave replikacio. par parametert gondosan kell beallitani (pl auto_increment_increment es auto_increment_offset), figyelni a replikacio tipusra (statement-based vs row-based) es konnyen uzemeltetheto. a SQL_SLAVE_SKIP_COUNTER akkor jo ha valamelyik query lefutott egyik node-on de a masikon nem tud. ilyenkor kezzel tovabb lehet lokni, kijavitani a hibat, majd a db tartalmat is helyrehozni.

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

az mm replikacio pont semmire nem jo, egy komolyabb hiba eseten olyan kaosz tud belole keletkezni hogy sosem hozod helyre, az egesz koncepcioja szar.
kis forgalmu site ala egy sima master-slave kell es atallni a slave-re ha gond van (ezt egy mysql proxy gyonyoruen elvegzi automatikusan, raadasul nem time-szenzitiv adatokra csodasan lehet hasznalni a replikat olvasasra es nem csak ott all a gep idle-ben).
nagy forgalmu site-ra meg galera vagy percona. mindketto ingyenes, es ahol 2 gep van ott csak akad egy 3. is, szoval nincs miert jelenetet rendezned :)

Végül Active-Standby konfiguráció mellett döntöttem, előtét szervernek meg egy HAPROXY-t (tudom, single point of failure, de megintcsak 1 node-ot kértek) ami mindig csak az aktívba ír/olvas, így egyenlőre nem ütköztem problémába.

Még egyszer köszönöm mindenkinek a segítséget.

---
Egy nap 24 óra, plusz az éjszaka!

Megkérdezhetem, hogy élesben is használod-e a galera-t? Csak azért kérdem, mert én használtam volna, lehet én csesztem el valamit, de alap sysbench-el tesztelve viszonylag kis számokkal is pillanatok alatt szétesett az egész, a node-ok kiestek a clusterből, majd újra beléptek, kezdődött az egész inicializálás előről. Próbáltam rsync-el, xtrabackup-al, fura de rsync-el katasztrofálisan lassú volt az egész, xtrabackup-al már tűrhetőbb, de azzal sem mondanám élvezhetőnek a teljesítményt. Ubuntu 18.04 és Mariadb 10.2 (MariaDB repo-ból telepítve) kombóval teszteltem.

Termeszetesen hasznaltam elesben, maskulonben nem dumalnek rola. ~50GB adatbazismeret, 3 node elotte mysql proxyval, kb. 100e ugyfelt kiszolgalo online jegyertekesito rendszer mogott uzemelt (nem magyar), soha nem volt vele gondom.
Elkepzelesem sincs hogy mitol lehet nalad hogy forgalomra szetesik a cluster, ilyet meg nem lattam, ott valami komoly hiba lehet, ki kell debuggolni.

nem vitatom hogy nem olcso, viszont joval megbizhatobb mint az ilyen valaki elso probalkozasa nehany google talalat alapjan osszetakolt cucc. Most komolyan, miutan ezt valaki igy osszerakta kezzel neked aki nyilvavaloan eloszor csinal ilyet, mennyire lennel biztos abban hogy ez megbizhato? vagy ez csak ilyen latszatnak van? Amig egy awsben futo stackre teljes nyugodalommal zuditok ra egy chaosmoneky-t addig egy ilyenre mennyire lennel magabiztos azt mondani, hogy "jatszunk el egy node failure-t productionben" ?

( hory v | 2019. 06. 03., h – 00:16 )

master-master, sql -el nem mukodhet. amit csinalsz, az egy iszonyatosan ronda hack, ami szejjel fog esni az elso alkalommal, amikor parhuzamosan modositjak ugyanazt az adatot a 2 node-on, vagy amikor eloszor nemdeterminisztikus query fut le.

Ha mar master-master replikacio kell, akkor mongodb. Ott van tisztesseges clustering, replica set-tel meg sharding-gal, nem ilyen ordenare hekk, ahol meg az se garantalt, hogy az adatbazis ugyanaz a 2 master-en (!!!).

Na persze lehet szart szallitani, sokan meg is veszik, de attol az meg szar marad, es sokat fogsz vele szenvedni, mert az alapjaitol alkalmatlan megoldas.