DRBD + HEARTBEAT + MYSQL

Linux-kezdő

Sziasztok!

A problémám a következő:

Adva van két node(node1 és node2, ezeken DEBIAN GNU/Linux (6.0.2) fut). A gépekre telepítve van a mysql, heartbeat és drbd csomagok. MySQL, DRBD és heartbeat bekonfigurálva, azaz ha a node1 elérhetetlen, nagyon szépen átveszi a node2 az ip címet , felmountolja a mysql meghajtót (ami persze a drbd-vel van szinkronizálva), majd elindítja a mysql-t, de sajnos, abban az esetben, amikor újraindul a node1 és ezeken a serviceket elindítom kézzel (/etc/init.d/ -ben a drbd, a heartbeat-et), és leállítom a node2, akkor nem veszi vissza a node1 a feladatokat. (Végülis nem akkora gond, mert vissza tudom kapcsolni a node1-re a dolgokat kézzel, de jó lenne, ha ez automatikusan menne vissza fele is).

Találkozott valaki hasonló problémával?

köszönöm

  • 2611 megtekintés

( budee | 2011. 09. 29., cs – 10:08 )

Umm, de egyertelmu, hogy ebben az esetben nem veszi at... ha kezzel inditod el a szolgaltatasokat arrol a heartbeat mit sem tud.

man hb_takeover

Amikor újra indul a node1 gép, azon kézel indítom el a serviceket, hogy ne legyen gond a két node között. Az lehetne automatikus, ha úraindítom a node2 gépet, és a node1 beállítaná magának a drbd-t primary-ra (visszaállítaná magát Secondary-ról), felmountolná a kívánt mysql könyvtárat, majd elindítaná a mysql-t

haresource fájlom:
.
.
.
node1 IPaddr::IP_CÍM/24/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/mnt/mysql::ext3 mysqld

A heartbeatnek tudnia kell arról, hogy a node2 meghalt, a log szerint látja is, de mint mondtam, nem állítja a drbd-t primary-ra, nem mountolja fel a mysql könyvtárat......

Csak akkor működik a dolog, ha a node1 hal meg, mert akkor a node2 megcsinálja amit kell (felvesz az ip-címet, primary-ra állítja a drbd-t, és felmountolja a kívánt könyvtárat, majd elindítja a mysql-t)

En ebben a haresource fileban ket hibat latok. Az egyik amit Kayapo irt feljebb, a masik, hogy debianban a mysql szerver initszkriptje mysql es nem mysqld. Javitsd ki ezt a kettot, es probald ujra.

Itt egy mukodo haresources:
be0 IPaddr::10.21.0.67/24/eth1:0 drbddisk::mysql Filesystem::/dev/drbd0::/srv::ext3::noatime mysql

( csardij v | 2011. 09. 29., cs – 11:08 )

Az miért jó, hogy egy olyan dolgot valósítasz meg bonyolultan, amit a MySQL maga is tud egyszerűen? (minél több réteg rakóik ár, annál több a hibalehetőség)

Én biztos vagyok benne, hogy te egy nagytudású szakember vagy, de tök feleslegessen írkálsz be ilyen hül*eségeket, ha nem tudsz hasznos információt írni, akkor ne írj semmit.

Ha már ennyire okos vagy, hogy oldanál meg egy adatbázis szervert (Master) úgy, hogy az arról replikáló gépek (MySQL replika SLAVE) gépek mindig elérjék azt a bizonyos IP-Címet/MASTER-t???????????????????????????

Nekem kell egy MASTER MYSQL, amiről a háttérben replikál 10 db SLAVE, a SLAVE gépeken futnak az olyan sql query-k, mint a select, stb..... A MASTER gép nem bírna el ennyi műveletet, ezert lett megvalósítva a terhelés elosztás. Mivel a gyenge pontom a MASTER gép ezért lett HEARTBET + DRBD megoldva.

Mégegyszer a kérdés:

Hogy oldanád meg egy elégé terhelt, adatbázis szerver magas rendselkezésre állását, és nem csak hogy magas rendelkezésre állás legyen, hanem a sebeség is fontos tehát a terhelés elosztást hogy a tök*mbe oldanád meg????????????

keepalive-et sehogy, mivel ha másik gépre kerül az ip, újra fel kell épülnie a kapcsolatoknak (honnét tudja a másik gép, hogy az előző kivel beszélt és mit).

De ez a heartbeates megoldásnál is játszik.

Vagy az alkalmazás és a mysql proxy közötti keepalivere gondolsz? Mert végülis ami proxyzik a mysql felé, akár az alkalmazás gépén is lehet, és a proxy dönti el, hogy hova kapcsolódik (ha elérhető a primary master oda, ha nem akkro a másik masterra, stb.), minden csak attól függ milyenre írod meg.

Tovább olvastam a témában, tehát a heartbeat már nem annyira jó, mert nem igazán van fejlesztve és ha jól tudom akkor csak 2 node-os fürtöt tud.

Viszont vannak problémák az értelmezéssel kapcsolatban:

Pacemaker az okés, az egy fürtökhöz készült CRM.
OpenAIS az egy fürt keretrendszer ( olyan, mint a heartbeat)

A corosync az mi is?

+1, nem azért mert nincs igaza, hanem azért, mert fölöslegesen írja be, alternatíva nélkül, hogy szar az egész. Ezzel senki nincs kisegítve. (később leírta külön kérésedre, de ez kihagyható lett volna) Marha unalmas, a céltalan fikázást olvasni, még akkor is, ha van alapja.

Általánosságban írtam, a lényeg, hogy nem írtál alternatívát, ill. pont írtál egy részére, de nem az egészre. A trollkodásért fikázni is trollkodás, nem is szoktam, csak most valamiért zavart. Egyszerűen az lenne a jó, ha egy kérdésre nem az lenne a válasz, hogy "miért csinálod szarul/bonyolultan" "minek ez egyáltalán", mert ezekkel senki sincs előrébb.

Én inkább egy multi masteres megoldásban gondolkodnék el, mint amilyen ez is:
http://mysql-mmm.org/

Szerintem a DRBD-s, Clusteres megoldás nem annyira bír jó teljesítménnyel. De mivel ezt nem próbáltam ez csak feltételezés. A tapasztalat azt mutatja, hogy a DRBD-t inkább sima storage-nak jó. De kíváncsi vagyok a többiek véleményére. Amúgy az OCFS2 már nálam is esett szét, aztán szét is szakadt a DRBD két vége is. Szóval csak az egyikre írni - ott is.

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

( dblaci | 2011. 09. 29., cs – 12:25 )

Működnie kell, úgyhogy valamit elnéztél, pl.:

- a két haresource file ugyanaz (bytera), tehát mind2ben a node1 az elsődleges.
- elbukik a visszaszerzés, de azt látod a logban

összességében logold a ha tevékenységét fileba, és nézd meg pontosan mi történik. Lehet, hogy elkezdi a node1 visszavenni a cuccot, csak elbukik, és ezért marad node2nél.

Az ip visszaszerzés switchtől függően problémás lehet "valódi" lehalásnál, mert nem veszi át az ipt, mert "foglalt" a switch szerint. Ez elég kiszámíthatatlan.

Egyébként ez az egész drbd mysql amit minden hwotoban írnak, azért szar, úgy ahogy van, mert:
- a lehalt gép nem umountol, tehát az átvevő gép egy nem szabályosan umountolt fst kap, ami naplózótt fsnél jó esetben nem gond, fsck gyorsan lefut, és megy a mount.
- a nagyobb gond a mysql táblák sincsenek lezárva a mysql szabálytalan leállítása miatt, ergo a repair table elengedhetetlen minden táblára, legalábbis myisam típusú táblánál, különben durva adat sérülések keletkezhetnek, vagy csak nem engedi használni a "sárült" táblát...

Én ehelyett ezt csináltam (de mondjatok jobbat)
- adatok drbd-ocfs2 master-master.
- mysql: külön fs, master-master replikálás (valójában csak az egyik van használva, a visszaállítás egyszerűsítése miatt master-master) és a heartbeat csak a belső ipt adja át a "tartalék" mysql szervernek.

adat: drbd ocfs2 párossal mik a tapasztalatok? szemezgettem már ezzel a lehetőséggel is, de még nem foglalkoztam túl sokat a témával.

Mysql: Master Master megvalósítás nem tűnik rossznak, ennél a megvalósításnál ha jól sejtem mind a két master egyben slave is egymáshoz képest (azaz replikálnak egymásról).

A kérdésem az, mivel nem használtam még master-master megvalósítást/lehetőséget, terhelés elosztás végett, itt is felhasználhatok több slavet?

köszönöm a gyors és hasznos információdat

1: az az igazság, hogy komolyabb meghibásodás még nem nagyon volt, de kernel panic miatti reset már volt, és azt relatíve jól tűrte, amikor nem, akkor kiderült, hogy valami config nem volt jó. Elég érzékeny, és ugye nehéz élesben tesztelni, de a végeredmény elég fasza, koppkopp. Persze van backup is... Sebességgel sincs gond, nem ez a szűk keresztmetszet, hanem a gigabites sávszélesség, és a sas winyók.

2, 3: pontosan. Egymásnak a slavejei... Ebből kifolyólag nyilván lehet akármennyi + slave, bár az nálam speciel nincs. A masterek összeszinkronizálásához ha sok az adatbázis sokáig lock kell, ami lehet gáz, de ugye elvileg ez nem sűrűn van...

a drbd ocfs2t sokan fikázták már a hupon, de jobbat nem írt senki, és amiért fikázták, az tapasztalatom szerint nem is igaz... én is tanulok, úgyhogy várom, mi a jobb.

Kifejtenéd légyszi a drdb-ocfs2-t bővebben? arra vagyok csak kíváncsi, hogy miért szinkronizálsz egy clusteres fájlrendszert?

2 éve csináltam mysql clustert, ha jól emlékszem úgy van, hogy vannak data node-ok és vannak sql nodeok. Mindegyik data node-nak saját fájlrendszere van. (Ez egyben azt is jelenti, hogy a tárhely_igény=node_szám*db_méret)