MySQL Master Master replikáció hiba

 ( tigris | 2019. május 27., hétfő - 13:10 )

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.

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ő.

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.

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ó?

Többféle konzisztencia szint létezik, ez nyilván nem a legkeményebb. Vannak szituációk ahová ez pont jó.
https://en.wikipedia.org/wiki/Consistency_(database_systems)
Fogalmazzunk úgy, hogy nem rosszabb mintha csak 1 node lenne.

--
Gábriel Ákos

Nagyon szépen köszönöm a válaszokat.

A problémát a hibás query-nél jött elő, amit az alábbi paranccsal megoldottam.

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
Az alap értéke 0.

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

Nekem az a furcsa, hogy a legtöbb ilyen How to-ban nem említik ezt a paramétert.

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

Mert ezzel nem a problemat oldod meg, csak atleped azt a hibat ahol elakadt a replikacio.

Sajnos azt a rendszert amihez ez a cluster kell, nem én csináltam, így számítanom kell rá, hogy vannak benne hibák.

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

+1

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.

Köszönöm a tanácsodat, így is teszek :)

Egyébként a kolléga az adatbázis egyik tábláján állított karakterkódolást, ekkor "hullott szét" a cluster.

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

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.

tobbnyire az esz nelkuli temporary table replikacio.....mert az nem replikalodik a statement meg igen

+1 - nem is tudom, hol láttunk ilyet... ;-)

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!

Vagy használ inkább postgres-t.
--
Gábriel Ákos

+1

Igazából csak még 1 gép kell. Ahol 2 van, akadjon már egy harmadik is :) Vagy lehet, hogy csak én vagyok lusta, mert nem lenne kedvem 2 egymástól elmászott adatbázisban keresni az utolsó közös pontot.

+1 (plusz sok)

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 :)

Sajnos a megrendelő 2 gépet kért.

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

Tegyél 2 gépet, Master-slavenek, ha lehal a master, kézzel átállhatsz, miután meggyőződtél róla, milyen állapotban van a slave. Vagy lehet galera is, csak az nem lesz HA, ha bármelyik megáll, akkor megáll az egész, viszont az adataid meglesznek 2x.

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!

Egyenlőre a precíz darabolós gyilkos fog felszeletelni - a szó, amit keresel, az az egyelőre. :-P

+1

Köszönöm, legközelebb jobban odafigyelek.

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

ez olyan koszikos volt

es miert nem raksz a ket haproxyt a ket nodera, megkinalva egy keepalivedvel?
maris nem spof, de single entrypoint az ipd...

Mondjuk kértek 2 MySQL node-ot, meg 1 HAProxyt - tessék ott a 3 gép a rendes clusterhez.

Miért nem corosync, pacemakerrel oldottad meg?

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.

kell ala rendes halozat, 4 node sync replikacioval esik kel.... (wan)

Nem WAN-ra van az kitalálva. 4 nodenak meg mi értelme?

3 kurva telehely, master az adatkozpontban lakik a szoftver meg esz nelkul van megirva es szamit neki a latency....

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.

engem inkabb az lep meg hogy ilyeneket meg kezzel csinalgatunk. 3 klikk aws-ben es minden meg van oldva redundansan backupolva es mindennel egyutt.

azt kurvara kevesen fizetik meg, par honap alatt behozza az onprem vasat.
Illetve az AWS tudomasom szerint meg mindig nem tud RDSben multmastert...

RDS-ben eleve nincs ertelme a multimasternek, folyamatosan megy a hatterben egy replika es az Amazon automatikusan atall ra ha gond van a masterrel szoval rendundans a cucc magatol.

ott a latency...

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" ?

[Feliratkozás]

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.

Szia hidd el értem a véleményedet, de MySQL-t kért az ügyfél.
Mivel a MASTER-MASTER nem volt stabíl így egy Active-Standby felállást készítettem ami elött egy HAproxy van.

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