mysql tablak "replikalasa" tovabbi gepekre

Adatbázis: SQL, XML DB

Van egy mysql (innodb) adatbazisom, amiben csomo tabla van. De ezek kozott van 2 (nem nagy, max. par MB meretu) tablam, amit at kene vinni tobb gepre (szinten mysql szerverek futnak rajta). A replikalast azert tettem idezojelbe, mert nem csak mysql szinten tortento replikacio johet szoba, a lenyeg az, hogy az A gepen levo table1 es table2 tablak tartalma menjen at a B, C, D, ... gepek table1, table2 tablaiba (de az A gepen levo table3, table4, ... mar ne). Az egesz ugy lenne szep, hogy ha az adott slave gepen (pl. B) megtortenik a frissites, akkor rogton / nem sokkal utana le tudok futtatni egy shell scriptet.

Hogy lehet ezt szepen megoldani?

  • 1812 megtekintés

( bAndie9100 | 2015. 06. 18., cs – 12:13 )

sima replikálás megteszi a dolgot, sőt a fájlmásolás az innodb miatt kevésbé jöhet szóba.
replicate-do-table és replicate-ignore-table paraméterekkel jól behatárolhadot, miket kell átvinni.
"slave gépen megtörténik a frissítés" - milyen frissítés?
"le tudjak futtatni egy scriptet" - milyen összefüggés van az egy script és a db közt?

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

nem akartam a nyers ibd file-okat masolni :-) A replicate-*-table parameterek jok lehetnek, de a mysql replikacio aszinkron, es sose lehetek benne biztos, hogy mikor kerul at az adat a slave gepekre.

"slave gépen megtörténik a frissítés" - milyen frissítés?

a tablak tartalma

milyen összefüggés van az egy script és a db közt?

a script hatasara elindul egy esemeny, aminek akkor van ertelme, ha atjottek a friss adatok

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

hat a replikacio valoban aszinkron, de a keses nagy altalanosagban 0. erre figyelni kell amikor irod a progit es kesz. de az csak akkor gond ha dolgozol egyszerre a master es slave adatokkal.
ha csak a slave-n belul vagy, akkor az adataid jok lesznek, max a T ido pillanatban a T-x allapotot "latod". pl egy elozonapi report generalaskor ez jo (ellenorizve hogy T-x mar a mai nap)

btw, a scriptes (dump, rsync, restore) is "aszinkron", csak ott a keses tuti nem 0 :)

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

Ez a tudjam mikor jött át elég fura, tudnál mondani egy példát miért fontos ez?

A mysql replikáció több lépcsőből áll egyrész van az IO thread ami kapcsolodik a masterhez és a kapott adatokat leírja relay logba. Szóval az adatod ekkor jött át.
De ha azt szeretnéd tudni,hogy az adott transakciot mikor hajtotta végre az már megint más kérdés.

Jelenleg nem tudok olyan Mysql megoldásról ami garantálná azt hogy a masterren történt insert abban a pillanatban a slaven is megtörténik. még a mysql cluster megoldásoknál sem. az adatátivel ugyan szinkron és chekkolja hogy az adott insert végrehajtható e slaven , de maga a végrehajtás már minden slaven aszinkron.

Nem elegendő ha van egy datetime fielded és a sciptet mikor futtatod akkor az adott időpillanat elötti adatokkal dolgozol csak?

Jelenleg nem tudok olyan Mysql megoldásról ami garantálná azt hogy a masterren történt insert abban a pillanatban a slaven is megtörténik.

de nem is ez a feladat :-) Nem gond, ha egy ertelmes idovel kesobb jelenik meg az adat a slave-eken.

Ez a tudjam mikor jött át elég fura, tudnál mondani egy példát miért fontos ez?

mert egy program ujraolvassa a tablat, amibol compile-ol egy listat. Ha tul hamar indul az ujraolvasas (az egesz tablat kell), akkor out of date adatok lesznek leforditva -> ezert szabad csak azutan ujrahuzni a listajat, miutan az egesz tabla frissult.

Nem elegendő ha van egy datetime fielded

nem, mert az egesz tablat olvasni kell (amugy jelenleg nincs datetime oszlop a semaban)

--
"what is mostly works", "mods that I describe is choosed" (hrgy84 "nem vagyok anyanyelvi angolos")

( Frantique v | 2015. 06. 18., cs – 12:21 )

Több megoldás van. Az egyik (a legkézenfekvőbb) a master-slave felépítés.
Ha ez nem lehetséges, akkor írj egy transmitter szkriptet az egyik oldalon, ami megfelelő formátumban szolgálja ki az adatokat, a másik felén meg egy receiver, ami beírja a megfelelő helyre. A polling policy-t te határozod meg.

--
Coding for fun. ;)

Mivel semmit nem tudok az adatokról, feltételezés alapú vázlatot csinálok:

Legyen a MASTER a replikálni kívánt tábla, amely adatai a SLAVE-be mennek. Feltételezzük, hogy a MASTER rendelkezik egy autoincrement értékű mezővel, esetleg egy időlenyomattal. Ebben az esetben a query úgy épül fel, hogy minimum értéknek megkapja ezen mező értékét a futtató szkripttől (lehet egy GET paraméter pl.):

select * from `MASTER` where `mezo` > GET_ÉRTÉK;

A transmitter lefuttatja, és átadja a receivernek (on-demand). A receiver válaszként megkapja a transmitter által kiolvasott adatokat, amelyeket feldolgoz és beilleszt a SLAVE-ba.

A receiver mindig kiolvassa a SLAVE-ben levő `mezo` MAX() értékét, és azt adja át GET-ben, így mindig csak a friss adatok jönnek. A sűrűséget te állapítod meg, emellett triviális hibaszűrés is van a módszerben: ha nem jött adat, akkor a SLAVE-ben levő `mezo` se nőtt.

--
Coding for fun. ;)