MySQL szinkronizáció

Linux-kezdő

Sziasztok!

Az lenne a feladat, hogy kettő különböző szerveren a MySQL adatbázisok ugyanúgy nézzenek ki.
Ugyanazok az adatbázisok, ugyanolyan adatokkal, ugyanolyan felhasználói nevekkel.
Az egyik gép az éles szerver, a másik meg lesz a 'pót'.

Most eddig eljutottam, de persze lehet, hogy rossz úton járok:
Az éles gépen megvannak külön fájlokban az sql fájlok, de megvan egy nagyban is, mert minden este megcsinálja automatikusan.
A 'pót' szerverre lehúzom a . gz fájlokat, csak az a kérdés, hogy milyen scripttel? parancssorral? töltsem vissza?

Ti mit javasoltok erre a feladatra?

  • 77021 megtekintés

( gergelykiss | 2013. 11. 17., v – 10:53 )

Ha egyfajta failover megoldásként szeretnéd ezt használni, akkor javaslom, használj DRBD-t a két szerver között (feltéve, hogy gyors hálózati kapcsolat van köztük, a legjobb, ha direktben össze vannak drótozva gigabites kapcsolattal).

A DRBD-n létrehozol egy ext3 vagy ext4 fájlrendszert, majd erre (a mysql leállítását követően) átpakolod a /var/lib/mysql könyvtárat, utána az eredeti helyről symlinkelsz a DRBD-s elérésre.

Ha érdekel, tudok küldeni egy általam készített részletes step-by-step leírást a folyamatról.

Előnyök:
* nem igényel extra konfigurálást a MySQL-ben (bár egyáltalán nem körülményes egy active-passive replikációt beállítani)
* mivel a DRBD szinkron módon működik, mindig a legfrissebb adatok lesznek elérhetők mindkét szerveren
* pillanatok alatt át lehet állni a tartalék szerverre (DRBD-t felcsatolod és elindítod a mysql-t)
* heartbeat/pacemaker segítségével automatizálható az átállás az éles szerver leállása esetén

Hátrányok:
* ha nincs direkt kapcsolat a két szerver közt (pl. csak neten keresztül látják egymást), akkor lelassíthatja a MySQL működését
* nincs loadbalance lehetőség (mindig csak az egyik szerver futhat, nincs lehetőség a tartalék szervert read-only műveletek kiszolgálására használni, mint a sima master-slave replikációnál)
* ha a szerverek elvesztik a kapcsolatot egymással, split-brain állapot alakulhat ki, de ez redundáns hálózattal (pl. 2 cross kábel használata trönkben) orvosolható
* a konfigurálásnak van néhány buktatója, amire oda kell figyelni (pl. azonos UID/GID használata a két szerveren a mysql futtatásához)

Nemrégiben egy 2 szerveres failover környezetben csináltam ilyet, ahol mivel csak 2 node van, nem lehetett rendes cluster-t építeni. Egyelőre úgy tűnik, jól bevált, és praktikusabb mint a master-slave replikáció.

Nekem például emiatt:

* mivel a DRBD szinkron módon működik, mindig a legfrissebb adatok lesznek elérhetők mindkét szerveren

Mikor körbejártam a témát, az első opció a master-slave replikáció volt, de mégsem tetszett benne, hogy inkonzisztencia lehet az adatokban a replikáció aszinkron volta miatt.

Plusz hátrány 2:
A szinkron replikálás növeli az adatbázis műveletek késleltetését. Minél messzebb van egymástól hálózatilag a két gép (lassabb net), annál durvább lesz ez a jelenség.
Az általam látott, valamirevaló rendszerek jelentős részében az adatbázis i/o teljesítménye a "leggyengébb láncszem", és már replikálás nélkül is a teljesítményre vinnyog az ügyfél.

Igazad van, de ezt én is megemlítettem az eredeti posztomban:

* ha nincs direkt kapcsolat a két szerver közt (pl. csak neten keresztül látják egymást), akkor lelassíthatja a MySQL működését

Az általam konfigolt kétszerveres környezetben nem a teljesítmény növelése vagy az ötkilences rendelkezésre állás volt a cél, hanem hogy egy viszonylag megbízható failover megoldást ki tudjak hozni az ügyfél által kifizetett 2 szerverből (korábban egy négyszerveres MySQL Cluster üzemelt itt). Sajnos jelen esetben a pénz beszélt, nem a technológia. :(

Akkor kijavítom pontosabban:

Akár direkt kapcsolat van a két szerver között, akár nem, biztosan lelassítja a Mysql működését. Hogy mennyire, az függ a hálózati késleltetéstől. De alsó hangon minimum a duplájára nő a dupla diszkvárakozás miatt. Ha a hálózat nagyon lassú, esetleg csomagok vesznek el, akkor látványos (akár másodperces!) is tud ez lenni.

Pontosan ismert tény, hogy szinte minden ügyfél szarból akar várat építeni :D

"mivel a DRBD szinkron módon működik, mindig a legfrissebb adatok lesznek elérhetők mindkét szerveren"
A replikacio 3 lepesben tortenik:
1, master szerver irja binlog-ba az iras muveletet (pl: 'insert into kutyafule (a,b) values (1,2)' utasitas) ami vegrehajtott
2, slave szerver masolja magahoz binlog file-ok tartalmat szinten csak local file-ba
3, slave szerver az atmasolt file-okbol vegrehajtja az irasmuveleteket

Ebbol a harmadik lehet lassu igazabol (bar 5.6-ban mar van paralell replika betoltes, de csak kulonbozo adatbazisokkal, de ez is csak erosen iras intenziv kornyezetben szamit).
Elso megtortenik azonnal, masodik pedig hacsak nincs 10M-s linkkel osszekotve vagy nagyon lassu diszken tarolva a binlog szinten lenyegeben azonnal, vagyis ha meg is all a master szerver kb annyi adatvesztes lehet mint magabol a megallasbol hogy utolso muveletek ki tudja befejezodtek-e vagy hogyan.

"pillanatok alatt át lehet állni a tartalék szerverre (DRBD-t felcsatolod és elindítod a mysql-t)"
Ezzel majd akkor lesz gondod ha innodb-ben tarolsz tobb adatot, ami miatt maga az sql szerver leallitasa/elindiitasa lassu, foleg ha nem sikeres a leallitas, mert akkor redo logokbol kell helyreallitani amig te malmozhatsz.

"heartbeat/pacemaker segítségével automatizálható az átállás az éles szerver leállása esetén"
Master-slave replikabol is konnyen lehet csinalni master-master replikat akar, amihez szinten lehet heartbeat/pacemaker resource kezelest beallitani, hogy ip-t atbillentse replika figyelessel (percona is ajanl ilyet ha jol tudom mmm helyett, bar egyszerubb helyekre mmm is eleg lehet)

Ha esetleg szethullik a replika, mert peldaul elfogyott a hely es nem tudta kiirni binlogot vagy valami akkor nem fogja automatan kijavitani de vannak ra tool-ok amivel lehet ellenorizni es javitani akar hasznalat kozben is, illetve par dolgot be kell allitani hozza valoban mysql-ben, de nem nehezebb mint drdb-t osszerakni jol mysql ala.

Köszi a lenyűgözően részletes választ. :)

A master-slave replikációval kapcsolatban köszi az infókat, én azt tapasztaltam a tesztnél, hogy kellett pár másodperc, amíg a slave-en megjelentek a master-en módosult adatok, persze lehet, hogy csak a konfig nem volt tökéletes. Nyilván nem egetrengető probléma ez a néhány másodpeces késlekedés, de számomra valahogy szimpatikusabb volt a DRBD működése, ahol gyakorlatilag csak az az adat létezik, amelyik mindkét szerveren le van tárolva.

InnoDB-t nem használunk, úgyhogy a mysql indítása közben (hacsak nincsenek sérült táblák) nem lehet fennakadás. Ettől függetlenül természetesen jogos, amit írsz.

Szempont volt az is, hogy ne legyen "gányolásos" a megoldás, illetve a "keep it simple, stupid" elvet követve minél egyszerűbb legyen. Nem akartam saját szkripteket írogatva megoldani, amik éles helyzetben vagy lefutnak úgy, ahogy kéne, vagy nem.

Igen. "failover" megoldásként szeretnék egy másik szerver. Ha valami tönkre megy az éles gépben, akkor beslattyogok a 'pót' szerverrel, s a hiba kijavításáig ez üzemelne. Persze a legutolsó mentési adatokkal.
Addig már eljutottunk az egyik ismerősömmel, hogy a 'pót' gépen már - majdnem - ugyanaz a rendszer van. (debian, squirrelmail, ispconfig). S most jönne az adatok áthúzása és beállítása. Ennek az egyik lépése a MySQL adatok áthúzása.
Egyébként nem 'online' adatkapcsolat lenne a két gép közt, hanem naponta 1-szer történne az adatok replikációja.