mysql replikálás nem a beépített SQL Thread-del

Adatbázis: SQL, XML DB

Szerintetek mennyire veszteséges egy mysql replikációt nem a mysqld saját beépített módján "etetni", hanem `mysqlbinlog relaylog.000001` -szerű parancsok kimenetét közvetlenül beletolni?

Az IO Thread mehet nyugodtan, az lehúzza a binlogokat,
viszont (mysqld verzió különbség miatt) az SQL Thread hibára szokott futni, ezért egysmás statement-et át kéne írni amit a SLAVE végrehajt.

Így arra gondoltam, hogy programatikusan átiratom a problémás részeket az olvasható binlog kimenetben és azt futtattatom le a SLAVE-vel.

Kérdés, hogy a bináris loghoz viszonyítva minden információ benne van-e a mysqlbinlog paranccsal visszakapott SQL szkriptben, vagy veszteséges; és az hogy alkalmazható-e ilyen formában: 


mysqlbinlog relaylog.000001 | my_convert_script | mysql -h localhost

Ignorált adatbázis, tálba nincs, de több adatbázist is tartalmaz a binlog, és mixed formátumú (igaz, az átírkálásokat a statement formátumú részekben kell elvégezni).

Gyakorlati megvalósításképpen gondoltam arra is, hogy 1. minden binlog utasítást a fenti formában kapna, vagy 2. ha a SHOW SLAVE STATUS hibát jelez, az adott pozícióban lévő részt szedném csak ki a mysqlbinlog paranccsal és konvertálnám át és futtatnám le, utána a pozíció (és esetlegesen a relaylog fájl) léptetésével újra elindítanám a SLAVE-et.

update
nagyszerűen gyakorlatias és probléma-orientált a HUP közössége, segítőkészek vagytok a rendszerek rendszergazdabaráttá tételében, és a problémákat okozó folyamatok leghamarabbi ponton történő javításában.
ugyanakkor jelen kérdésemmel (és a legtöbb kérdésemmel, amit nem úgy kezdek, hogy "mit csináljak másképp") csupán a mysql és különböző verziói működésére vagyok kiváncsi egy olyan elméleti szituációban, amikor a replikáció SQL Threadjét kéne emulálni mysqlbinlog parancs kimenetének végrehajtásával.

  • 2379 megtekintés

( dotnetlinux | 2015. 11. 18., sze – 20:12 )

Veszélyes terep, de nem kivitelezhetetlen...

Mennyire vannak messze az SQL-ek? Nem fizikálisan, hanem verzióban és felügyeletben? Nem lenne jobb mindegyiket felhúzni 5.6-ra? Utána dönthetsz, hogy master-slave vagy Percona XtraDB Cluster.

@blackluck @csardij
Nem akarok a pontos hibajelenségbe belemenni.
sztem nem igaz hogy nincs olyan sql utasítás ami 5.5-ön nem dob hibát és 5.6-on hibát dob azonos táblaszerkezet és azonos Variables mellett.

persze, meg lehetne közelíteni úgy hogy írjuk át kompatibilisebbre a master-on lefutó kódot, vagy frissítsünk föl mindent, vagy írjuk át DBaseIII-ra, de amit a kérdésben adott, attól ebben a topikban nem akarok eltérni.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Te tudod, de kritikus alkalmazas az ott indul, hogy a-z-ig ugy van megirva, hogy peldul az elvart replikacios dolog mukodik. Ezen felul ha ra is futottal bizonyitott inkompatibilitasra, es nem a bugra amit fentebb irtak, akkor illik azonos verziora hozni, esetedben 5.6-ra es ha ugy is hibat ad akkor javitani a kodot. Tobben leirtak mar, hogy a keresztbe hegesztesz nem tul egeszseges.

a keresztbe hegesztesz nem tul egeszseges

oké értem. arra lennék kiváncsi, hogy tudsz-e valami konkrét tényről, ami egészségtelenné teszi a témaindítóban felvázolt módszert. pl. nincs `USE dbname` a kimenetben, vagy hasonlók. nekem is van némi megérzésem, hogy rejthet buktatókat a dolog, de igyekszem a döntéseimet minnél kevesebb megérzésből és minnél több tényből meghozni :)

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Maga az, hogy a beepitett megoldast probalod megkerulni. A beepitett megoldas velhetoen nem veletlenul mond hibat. Az emlitett problema kivaltoja pedig minimum elgondolkodtato. Egy unsigned tipusu es 0 erteku mezobol barmennyit kivonni erdekes otlet, mert tulcsordul a valtozo.

Azt mar nezted, hogy ha a masterrol normalisan mysqldump-pal csinalsz dumpot az siman bemegy-e a masterre vagy a slave-re? Ez foleg egy mentes visszaallitasi teszt.

nyilvan nem veletlen. azert van mert megvaltozott az unsigned mezok kezelese. megjegyzem, szerintem logikusabb az uj alapmukodes. oke, elolvastam a doksit, mi valtozott, elgondolkodtam, megallapitottam h a futo kodnak nagyon jo lesz tovabbra is ha ott abban a mezoben 0-1=0 lesz. a mysql uj verzioja tovabbra is tudja ezt a mukodest produkalni, ha megadom a megfelelo sql_mode opciot. de a replikalo folyamat felulirja az opciot, barmit is allitok be a masteron.

a dump betoltesevel nem lehet gond a szoban forgo szempontbol. ott egy diszkret erteket insertel be a tablaba, nem allhat fenn a tulcsordulas kerdese.

a fo kerdesem tehat, miben terhet el a slave sql thread altali relaylog feldolgozas a relaylog olvashato formajanak mysql kliensen kereszuli futtatasatol?

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Maga a felolvasas semennyiben, a gond a custom, odataknyolt sajat SQL-atalakito scriptben van, aminek a jo isten tudja, milyen lesz a minosege, a throughputrol nem is beszelve. Error-prone, nem is javasolt igy csinalni, szep sem, raadasul ha baj van, senki nem fog tudni neked erdemben segiteni, abban meg nem lehet megbizni, hogy a slave ugynazt tartalmazza, mint a master, hiszen ez nem klasszikus master-slave replikacio, itt a "show slave status" egy nagy budos nullat fog visszaadni, fuggetlenul attol, hogy van-e hiba vagy nincs.

El fogod vesziteni az osszes garanciat, amiert egyaltalan erdemes master-slave felallast epiteni. Ennyi erovel atalakithatnatok ugy is az appot, hogy egyszerre ket MySQL-ben usse le az irasmuveleteket, es meg az is sokkal biztonsagosabban uzemeltetheto lenne, mint az a taknyolas, amit most csinaltok. Persze tudom en, mi van, a cegvezeto nem akar a fejleszteser fizetni, oldjatok meg okosban.

Nezd, eszed-nem eszed, ha azt akarod, hogy egy ertelmesen uzemeltetheto infrad legyen ket valasztasod van:
- Upgradelsz
- Downgradelsz

Minden massal meg fogod szivatni magadat, de durvan.
--
Blog | @hron84
Üzemeltető macik

egy szó sem esett arról, hogy mit tartalmazna vagy akárcsak milyen bonyolult lenne a custom script?!
egyébként hót eccerű, nagyjából:
s/SET session.sql_mode=(\d+)/SET session.sql_mode=`$1 | 64`/
:D
(most nem tudom pontosan hogy mennyi a no_unsigned_substraction-nek a számértéke, asszem 64)
ilyen apró beletaknyolástól azért nem lesz annyira torz, csak éppen le fog futni a nulla minusz egy.

igen, a show slave status el fog veszni ha az egészet binlogot beletolom, mint a témaindító utolsó bekezdésének 1-es pontjában, de arra ott a 2. pont amikor mindig csak a problémás binlog bejegyzést tolom bele ílymódon.

a többire nem kívánok reagálni, mert nem tartozik a kérdéshez az hogy milyen humán-háttérben merült fel. nincs app, nincs cég, nincs vezető, nincs infra.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Figyelj mar, lehet jobban jarnatok valami mysql-proxyval akkor mar, az le tudja asszem utni az iras muveleteket egyszerre ket SQL-ben, es akkor az futna le, amit az app kiad. Ha annak van ertelme mindket szerveren, akkor ez biztonsagosabb lenne, mint belenyulni kezzel valamibe, amibe nem kell belenyulni.

Az a problema, hogy ha _barmi_ miatt nem fut le a scripted, mert pl. epp frissul a sed csomag, es atmenetileg nincs mukodo sed binaris a gepen, akkor ugy elcsapja magat az egesz, mint a huzat. De teljesen mindegy a script tartalma, felolem egy cat is lehet, az is error prone, mert mar fugg az egesz valaminek a mukodesetol, aminek semmi koze se a mysql-hez, se a replikaciohoz. Van egy problematok, es nem a problemat oldjatok meg, hanem a tuneteket, es ezzel van a baj.

Egy kerdes: mekkkora melo lenne azt az 5.6-os MySQL-t downgradelni egyezo verziora?
--
Blog | @hron84
Üzemeltető macik

negyvenedjére: igen, sokkal hasznosabb lenne az eredő problémát megoldani. nem, nem az eredő problémát szeretném ebben a topikban megtárgyalni.
ha lesz egy olyen topik, hogy "hogy kell nulláról beállítani egy mysql replikálást", akkor ott nem próbálom a taknyolmányom felé terelni a szót.

amit o kitalalt hogy lehet megvalositani

a témaindítóban már egy megvalósítást írtam, kiváncsi arra vagyok, pontosan és tényszerűen milyen mellékhatásai lehetnek.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

A probléma az, hogy elvárod hogy mi adjunk ötletet hogyan javítsd ki a "taknyolmányod". Nem, erre senki nem akar vállalkozni, mert úgy szar ahogy van. Ne vágyj arra hogy mi a te taknyolmányodba taknyoljuk térdig, erre mi sem vagyunk vevők. Ajánlottak alternatívát: downgradelsz, upgradelsz és megcsinálod normálisan, vagy összetaknyolod magadnak ahogy most is.

És hogy miért nem akarunk taknyolni? Mert a probléma a lehető egyszerűbben orvosolható: downgrade/upgrade, amire ellenérvet nem hoztál

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

Negyvenegyedjere is megkerdezem, mert ugy latom, nem birod felfogni, hogy minket csak eszervekkel gyozol meg: pontosan miert nem opcio az, hogy valamelyik oldalt azonos verzioval hozod, akar downgrade-del, akar upgrade-del?

Most egy pillanatra tekints el attol, hogy nem a taknyolmanyodra akarok reagalni, csak ugy, egyszeruen, valaszolj a kerdesre. Az is jo valasz, ha azt mondod, hogy nem mondhatod el, mert uzleti titok, NDA kot, vagy a tokom tudja mi, csak ne jatszd itt a fafejut, mert az nagyon rosszul all neked, nekem meg mar tele van szalkaval a kezem.
--
Blog | @hron84
Üzemeltető macik

erre szerintem már korábban válaszoltam

tisztában vagyok vele, hogy [...] van rá más megoldás (lehet h azok egyikét alkalmazom, majd kiderül, offtopic)

tehát hogy világos legyen: a konkrét esetnél igenis opció a downgrade/upgrade.

az én kérdésem: fafejű-e az aki nem érti, mi az az offtopic?

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Itt az volt a gond, hogy nem kommunikáltál tisztán, egy zárójeles megjegyzésből elég nehéz következtetéseket levonni.

Csak hogy értsd: előjöttél egy olyan problémával, amire az a bevált és garantáltan üzemeltethető megoldás, hogy megszüntetjük a probléma forrását, így vagy úgy; ehelyett te bemutattál egy olyan megoldást workaroundot, amihez normalis üzemeltető ha lehet nem adja a nevét, mert rengeteg sebből vérzik az egész, majd megkérdezted, hogy mennyire vagy nagyon hülye. Amikor közöltük, hogy nagyon, akkor viszont ezt nem vetted jó néven.

Félreértés ne essék, van olyan scenario, amikor a felvázolt workaround az egyetlen értelmes megoldás, de ehhez az kell, hogy minden más, normális utat kizárjunk így vagy úgy, pont azért, mert ezek a fajta megoldások az ún. last resort kategóriába tartoznak, így akkor oldunk meg problémát, ha már az összes lehetséges _jó_ megoldási lehetőséget számba vettük és kimerítettük, ugyanis ez nem megoldása az eredeti problémának. Ez egy workaround, annak is elég csúnyácska szegénykém, ráadásul az összes garancia veszélybe kerül, amiért érdemes replikációt üzemeltetni.

Ha nekem ilyen megoldással kapcsolatos javaslatra lenne szükségem, feltétlenül leírnám, hogy az egyéb fajta megoldásokkal (upgrade, downgrade, proxy) tisztában vagyok, és hogy tájékozódtam a témában, ugyanis ez csak a te fejedben egy adott dolog, mi nem tudjuk, hogy te mennyire vagy képzett ezzel kapcsolatban.

Mivel ez nem történt meg a legelején, ezért ment el ez a szál abba az irányba, hogy inkább azt taglaltuk, miért hülyeség az, amit szeretnél, mintsem, hogy belemenjünk egy ilyen megoldás támogatásába. És továbbra is tartom, hogy ez a megoldás ellenjavallt szinte minden fontosabb scenarioban, amikor felmerülhet az igénybevétele, mert nem támogatott, mert manuálisan nyúlkál bele a replikációba, és mert semmi garancia nincs, hogy ezt helyesen teszi.
--
Blog | @hron84
Üzemeltető macik

köszönöm, teljesen jó hogy mostmár ugyanúgy látjuk a helyzetet.

a témaindítómban megemlíthettem volna, hogy a háttértörténetre nem kell figyelmet fordítani.
de nekem már csak ilyen poroszos iskolás a stílusom: ami a kérdésben szerepel, csak az létezik.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

köszönöm, az ötletemnek legalább egy buktatójára felhívtad a figyelmemet: hibakezelés a custom szkript összetevőinél.

de a többi választ - ne haragudj - de kb. ehez hasonlítanám:

Q: Szerintetek ha porcukrot keverek a piskóta tésztába, akkor kaphatok a kristálycukrossal egyenértékű süteményet? ha nem, miben fog eltérni?
A: Elvileg egyenértékű de az a megérzésem, hogy porcukorral nem ugyanolyan. Mennyiből állna ha sültkrumplit ennél helyette, vagy elmennél egy cukrászdába?

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( hrgy84 | 2015. 11. 19., cs – 09:55 )

Szerintem is elegge veszelyes terep, es en nem vagnek bele ugy, hogy nincs egy verzioban egyezo slave-m is valahol - biztos ami biztos. Szerintem sok nyugot veszel a nyakadba, erdemi nyereseg nelkul, en inkabb upgradelnem azt az 5.5-ot.
--
Blog | @hron84
Üzemeltető macik

( ody42 v | 2015. 11. 19., cs – 12:08 )

Nem egy életbiztosítás, amit csinálni akarsz, sőt, ahogy többen írták, ennek mennie kéne, lehet, hogy már most inkonzisztens a slave, és azért esik le a replikáció.

Amennyiben mégis hackelni akarsz, akkor már inkább ezt csináld:
1. monitorozd a SHOW SLAVE STATUS-t a slave oldalan
2. amikor leesik a replikáció, akkor olvasd ki a relay log file / pozicion levo statementet, és alakítsd át olyanra, amiről tudod, hogy megeszi a slave, majd hajtsd végre a slaven.
3. utána a slaven: SET GLOBAL sql_slave_skip_counter = 1
4. start slave

Illetve azt nem működhet, hogy a masteren csinálsz egy triggert, és azzal kezeled a problémát?

Én egy ilyen hack után azért szorgosan gyártanám a backupokat a masterről, és a két utolsó backup közötti összes binlogot megtartanám.

köszi, ugyanerre jutottam az utolsó bekezdés 2. pontjában.
azzal a különbséggel, hogy nem skippelni gondoltam ha nem újra pozícionálni, de igazad van talán egy egyszerű skip jobb lenne - bár nem tudom elképzelni hogy nagyon más csinálnának.

ha a before trigger tud olyat hogy azt az utasítást, amire triggerelődött, elnyeli, nem engedi lefutni - hanem az átalakított utasítást futtatja le helyette, akkor ez is egy jó gondolat. erre nem gondoltam.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Szia!

Nem kell elnyelnie a triggernek az eredeti SQL statementet.
Ha a slaven beallitod a skip_slave_error-t arra az error tipusra, akkor benne is maradhat a binlogban, a SLAVE konzekvensen nem fogja leallitani a replikaciot erre a fajta hibara.

Bővebben itt:
http://dev.mysql.com/doc/refman/5.5/en/replication-options-slave.html#o…

nem az okoz hibát hogy már inkonzisztens lenne a slave.

nem akarok belemenni, nem tartozik szorosan a kérdéshez, de úgy látom nagyon akartok hallani a konkrét eset kontextusáról :)
bigint unsigned tipusú mezőnél von ki 0-ból 1-et a master és a binlogba belekerül SET sql_mode, ami kiüti a globálisan beállított sql_mode=no_unsigned_subtraction opciót.

de ismétlem, a kódot nem lehet / nem kell javítani ami futtatja ezt a query-t.
illetve elképzelhető a jövőben más olyan konkrét eset is, ami megkívánja a binlog programozott átírását. ezért úgy tettem fel a kérdésemet ahogy.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Aha, szoval ha jol tippelek 5.5-os mysql-bol is 5.5.5-nel nem ujabb ami miatt abban nem ad hibat:
https://dev.mysql.com/doc/refman/5.5/en/sql-mode.html#sqlmode_no_unsign…
Ami mellekesen max valami Beta verzio lehet:
https://dev.mysql.com/doc/relnotes/mysql/5.5/en/
Igy valoban nem biztosan garantalt a replikacio tamogatottsaga es nyilvan mi gondoltuk rosszul, hogy normalis megoldast szeretnel takolgatas helyett (/Ironia off).

5.5-ből a debian által szállított stable mysqld fut a masteron.

mi gondoltuk rosszul, hogy normalis megoldast szeretnel takolgatas helyett

nem akarok megoldást. a konkrét helyzetet is csak azért írtam le mert mindenki "meg akarja javítani" azt a dolgot ami a témaindító kérdést szülte ( csak hogy ne vetődjön fel maga a kérdés :D ). tisztában vagyok vele, hogy jól tervezett, ideális IT rendszerben nem szabad ilyennek előfordulnia, meg hogy van rá más megoldás (lehet h azok egyikét alkalmazom, majd kiderül, offtopic). engem teoretikusan érdekel, hogy mi a helyzet egy ilyen "hátulról támadó" replikálással.
én tákolgatok ha a körülmények úgy hozzák :)

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

köszönöm. mondasz valamit.
mondjuk én azzal se vagyok tisztában, hogy mixed format-nál mi alapján dönti el a mysql, hogy mikor ír rendes statement-et és mikor BINLOG utasításokat. illetve hogy azokat hogy kell dekódolni :)

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Én azt gondolnám, hogy mixed esetben pl. olyat nem fog row based formattal loggolni, amikor egy sql statement sok sort változtat, hiszen az nem túl hatékony. Ha csak egy sor változik, akkor a row based sokkal gyorsabban végrehajtható _lehet_ a slave oldalon.

A mixed még akkor is hasznos, ha egyszerre többfajta adatbázist replikálsz, és az egyik mondjuk nem támogatja a statement based replicationt. (pl. ndbcluster ilyen)

( lajos22 | 2015. 11. 20., p – 11:43 )

Elég fura igénynek tűnik a binlog szerkesztése. Ha van kedved (akár privátban) részletezhetnéd nekem, hogy mi a konkrét feladat. hogy miért is így kell.

--
openSUSE 13.1 x86_64

köszi a készségességedet!
nincs konkrét feladat - azaz van de engem kimondottan a topikban leírt elméleti kérdés érdekel. nem kell mögé látni, nem kell megoldani magasabb szinten, nem kell áttervezni a nem létező infrastruktúrát :)

ha van tapasztaladot a binlogszerkesztésben, kérlek, ne tarsd magadban.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( secretx v | 2015. 11. 20., p – 19:25 )

Nincs mese itt uttoronek kell lenned, es vegig kell szivnod.
Abba azert gondolj bele hogy ennek van egy eros miertje is, es nyugtass megbez nem egy prod kornyezet