MySQL replication

Adatbázis: SQL, XML DB

Tudom, hogy van sok ehhez hasonlo tema, de ez kevesse elter a tobbitol. Adott egy kliens, aki hasznal ket web applikaciot ket kulonbozo VPS -en. Jelenleg nem egy eromu ( 1GB RAM ), de mivel nemreg vagyunk tul az implementalason ( legalabbis az elso fazison ) meg nagyon kis meretu az adatbazis, termeszetesen allandoan novekszik ( nehany MB jelenleg ). Ha szukseges akkor 8GB RAM -ig tudjuk boviteni pillanatok alatt.
A ket VPS -t ket kulonbozo cegnel helyeztem el, ha gond van akkor nagyobb a valoszinusege, hogy csak az egyik fog elszallni.
Arra gondoltam, hogy jo lenne az adatbazisokat tukrozni a szerverek kozott ( tehat az A szerver AB -at tarolni a B szerveren es forditva. A kerdes az lenne, hogy ez mennyire fogja vissza a gepeket? Jobb lenne beallitani egy harmadikat szervert is?
Pontos statisztikakat nem tudok mondani, mert meg folyamatban van a cegnel az atallas a software -re, de nagyreszt olvasas tortenne ( az esetek 80-90% -ban ). Van egy nehany munkaallomas is, azok naponta ketszer, kulonbozo idopontokban szinkronizalnak a szerverrel ( pontosabban feltoltenek dolgokat )
Arra az esetre, ha nem mukodik az egyik szerver az atiranyitas mar meg van oldva, kimondottan csak az adatbazis replikacionak a gepre gyakorolt hatasa erdekelne.
A replikacio NEM semi-synchronous lenne, mivel a ket gep kulonbozo varosokban lettek elhelyezve es igy SZVSZ nagyon erezheto lenne a hatasa.
Inkabb gyakorlati tapasztalat erdekelne, a Zinterneten talaltam nehany szintetikus merest meg elmeleti kalkulaciot, de az nem tulzottan erdekel foleg mivel itt ua. a szerver lenne master is es slave is.
Koszonom!

  • 20459 megtekintés

( zoner | 2013. 07. 12., p – 18:28 )

Egy master mysql es ket slave, ami neked kell. A master-re mehet az osszes iras (esetleg web-es admin felulet az app-hoz), a ket slave-rol pedig olvasas.

De ez inkabb subscribe, en is kivancsi vagyok, hogy mas hogyan csinalja.

Ezt én eddig csak papíron próbáltam és egy dolog nem tiszta!
Egyik eset: közvetlenül írnak adatbázis szerverre, és olvasnak is
Másik eset: másik szerverről történik írás a slavere, hálózaton keresztül, ami akár egy újabb hibaforrás is lehet és mellette ugyanúgy van olvasás.

Nem kötekedés, láttam, hogy többfelé használják illetve ajánlják ezt a felállást, csak nem értem, hogy mit nem értek: miért jobb terhelés szempontjából a második eset?

Ha egy helyen megy az írás és olvasás is, nagyobb a valószínűsége, hogy lock-ra várás lesz. Terhelt szerver esetében biztosan elő fog fordulni.

Ha replikált adatbázissal dolgozol, akkor elég megbízható hálózattal rendelkezel, amely akár redundáns is lehet (kell lennie). Másrészt ha row-based-replication a replikáció típusa nem statement-based-replication, akkor lényegesen kevesebb ideig tart egy-egy módosítás érvényre juttatása a slave-eken, mert nem csinálja meg újra a masteren lefutott SQL-t, hanem csak a tényleges változás megy át a slave-re. Így a lekérdezéseknek nem kell várnia (annyit) egy-egy műveltre, mint az "egyik eset"-nél. Ha SBR a replikáció típusa, akkor annyiban nem mindegy, hogy a lekérdezés miatti lock nem akasztja le az egész szervert, a master teszi a dolgát, majd ha a slave befejezte, amit csinált, lock felszabadul, szépen beéri a mastert, ha közben volt változást okozó művelet. Ha több slave-ed van, és szétszóródnak köztük a lekérdezések, akkor az egymásra várás is egyértelműen csökkenni fog. Persze ez az RBR esetére is igaz.

itt kérdeznék én is egy olyat, hogy:
volna egy master-slave (esetleg master-2slave)
van egy alkalmazás ami INSERT-et generál (mondjuk telefonos CDR). ez ír a master-be.

van egy GUI, ahol a user nézheti a saját CDR-t, és mindenféle bonyolult lekérdezések segítségével leterhelheti a szervert. Na, ez a query menjen inkább a slave-re.
Az se gáz, ha utolsó pár perc (óra?) még nincsen sync-elve.

Van arra vmi instant megoldás, mondjuk olyan proxy ami a read kérést a slave-re, write-t a master-re küldi? Ha igen, akkor az applikációban nem kéne vakargatni, csak egy másik IP-t és vagy portot kéne neki megadni.

(rejtett subscribe)

akkor az applikációban nem kéne vakargatni, csak egy másik IP-t és vagy portot kéne neki megadni.

Azért az applikációk 99.99%-a nincs arra felkészítve, hogy ha nyom egy insertet, commitolja, majd rögtön ezután visszakeresi ugyanazt selecttel, akkor hopp, nem találja ott azt a sort. Szóval az ilyen architektúrákhoz, amit szeretnél, hozzá kell idomulnia az alkalmazásoknak, különben hasraesés lesz.

( djsilas | 2013. 07. 12., p – 19:58 )

Én hasonlót egy szolgáltatón belül csináltam, HAProxyval, és Perconával. (Két elszeparált szolgáltató/hálózat "közé" nem akartam csak úgy kiengedni MySQL-t. Akkor legyen egy VPN... Na igen, de mi és hogyan fogja figyelni, hogyha egyik node kiesik, az IP-nek változnia kellene a DNS rekordban és a többi, és a többi.
Virtualizált teszt környezetben próbálkoztam NDB Clusterrel, viszont annak idején a mi "szintünkön" túlzott erőforrásokat kért volna)

Úgyhogy leginkább ez is csak feliratkozás :)

A helyzet a kovetkezo ( 1 db szerverrol lesz szo ): adott tehat egy VPS ami Apache,PHP,MySQL es VPN kiszolgalo, domain nincs rairanyitva, csak IP cimrol elerheto. Van egy harmadik szerver ( egyszeru, shared hosting ). Amikor az ugyfel csatlakozik akkor a domain.tld/app cimen kapcsolodik, ott egy script varja ami eldonti, hogy ra van csatlakozva a VPN -re, vagy nincs. Ha igen, akkor atiranyitja a 10.9..... cimre, ha nincs, akkor a publikus cimre ( https + .htpassword ). Ha egyik sem elerheto akkor a masik szerverre kuldi at. Amennyiben menet kozben hullik el a szerver, akkor csak ujra ra kell kattintson a bookmark -ra ( ami termeszetesen a domain/app ), ami eldonti, hogy hova lesz kuldve.
Nincs tulmisztifikalva a dolog, annyi lenne a kerdes, hogy mennyire lassul be a szerver a szinkronizalas hatasara / ajanlott lenne egy szerver ami slave lenne mindkettojuknek?

( arpi_esp v | 2013. 07. 13., szo – 10:20 )

master-master replikacio jo erre, csak az autoincrementes trukk (2-esevel no, az egyiken paros a masik szerveren paratlan key-eket ad) is kell ha mindkettore akarsz irni, meg a kritikus dolgokat tranzakciokezelessel csinald.

a szoftvert kell ugy megcsinalni, hogyha esetleg elofordul split-brain (megall a replikacio, es a 2 szerver kulon eletet el, es mindkettore megy iras) akkor is ossze tudjon szinkronizalni, ne legyenek utkozesek.

A'rpi

( sharky | 2013. 07. 15., h – 21:36 )

Lehet, hogy felreerthetoen fogalmaztam: a replikacio feladata csak back -up, a 2 szerveren ket kulon applikacio fut. Egyszeruen egy cross-back-up ot ( nem ugrik be mas kifejezes ) szeretnek. Annyit szeretnek tudni, hogy mennyira lassitja le a szervereket, ha egymas koztott szinkronizalnak? Jobb megoldas lenne egy harmadik szervert hasznalni back-up -ra, vagy pedig a terheles nem lenne nagyon erezheto?
Megegyszer: mindket szerveren van 1-1 db kulonallo adatbazis ( semmi kozuk egymashoz ), a szervereken letrehoznek 1-1 uj adatbazist ami a masik szerveren talahato adatbazis masolata lenne. :)

elmeletileg ugyanannyira terheli a replikacios szervert amennyire a mastert az iras muveletek (ugyanazt hajtja vegre rajta). gyakorlatban ha mixed mode-t hasznalsz akkor akar meg kevesbe (mivel bonyolult statementek helyett csak az eredmenyt tolja at).
ha csak nincs valami szarra terhelt szervered akkor nem lesz gond.

viszont hogy ne vesszenek ossze a db-k, vagy futtass kulon mysql peldanyt a backupnak, vagy filterezd ki hogy mit replikaljon.

A'rpi

( janoszen v | 2013. 07. 15., h – 21:46 )

Valamiert ugy erzem, nem egeszten tisztaztad, hogy mire kell neked a replikacio. Ha mindenfele adatszinkronizalasra kell, akkor nem ez a megfelelo eszkoz, ezt alkalmazas szinten kell megoldani. Kulonosen ova intenelek a master-master konfiguraciotol, annak ugyanis van jopar buktatoja, amit szerintem igy elsore nem latsz.

Ezen felul klasszikus replikacio tevhiteket vegigveve:

Ha azert kell, hogy ne szalljon el az adat, akkor rossz helyen kapizsgalsz, mivel akkor Neked igazabol egy jol megtervezett mentes es visszaallitasi terv kell, nem pedig replikacio, mert azon bizony elofordulhat az, hogy a slave is korrupt lesz es elfogadja a zsebbe penzt. A helyes megoldas az, hogy csinalsz egy slavet es arrol csinalsz rendszeresen file mentest. Itt a slave akar ugyanazon a gepen is lehet.

Ha a rendelkezesre allast akarsz novelni, akkor elso sorban a kommersz VPS szolgaltatorol migralj valami komolyabbra, mert az arcsokkentes jegyeben ez lesz a legnagyobb korlatozo faktor.

Ha read IO problemaid vannak, akkor megint csak ugyanez a tanacs, migralj eloszor fizikai gepre, utana kezdd el elosztani.

Ha network latencyt akarsz csokkenteni, akkor megint csak nem sok ertelme van, mert Magyarorszagon belul (de meg EU-n belul is) elhanyagolhato.

Osszegezve: ha lehet, mindig torekedj az egyszerusegre, Ha tenyleg skalazodasi problemaid lesznek, majd megoldod. Jelenleg nemhogy ertelme nincs, de meg hatraltat is.

Koszonom!
Amire szuksegem lenne az valos ideju back-up. Termeszetesen meg tudom oldani applikacio szinten is, de ez egyszerubbnek es kezenfekvobbnek tunt.
A sebesseggel - egyelore - semmi gond nincs. Termeszetesen ezzel - ha nem is ez a cel - novelhetem egyszeruen a rendelkezesre allast, mivel egyik szerver nagyon egyszeruen atveheti a masik helyet ( fentebb leirtam a megoldasom )

Azert a valos ideju backup egy nagyon komoly kovetelemeny. Eleve force-olnod kell a statement-based replicationt, amit az alkalmazasnak tamogatnia is kell. Ha row-level replication van, akkor siman elcseszodhet a replikad. Ezen felul meg meg vagy egymillio buktato van a dologban.

Ami a rendelkezesre allast illeti, egy ilyen VPS-es setupnal ez kb olyan mint amikor kartyavarra akarsz lotornyot epiteni.

Egyelore csak nehany Mb/nap novekedes lesz, ennel tobbre egyaltalan nem szamitunk, sot, meg ez is tulzas. A query -k nagy resze SELECT, INSERT/UPDATE/DELETE ritkabb. Ha jol tudom akkor nem a query -k lesznek atkuldve, csak a binlog.

Rendelkezesre allas: ertem, hogy nem a legjobb megoldas, de azert egy fizikai vas - egyelore - agyuval verebre esete.

Fizikai vas esetleg 1-2 ev mulva lesz, amikor egy 4Gb RAM -os VPS mar nem birja kiszolgalni. Meglehet, hogy akkor sem ez lesz a megoldas, hanem pl arhivum keszitese, ahol a regi, mar nem hasznalatos adatokat athelyezzuk valahova.

+1, és én replikációt használok erre. Master-master, de csak azért, hogy karbantartáskor, vagy leálláskor át lehessen állítani. Valójában csak az egyik master és a másik slave gyakorlatilag adott pillanatban. (Az átálláskor global read only, nehogy split brain legyen). Ezen kívül van 24 óránként dump és file szintű backup is. A binary log miatt ha az egyik megmarad, akkor gyakorlatilag valós idejű mentés van, (elméletileg nem, mert elveszhet néhány másodperc, de az nem gond)

Szerk: és ez helyi hálón több gép, de simán mehetne Interneten, ha nem túl nagy a tényleges írás sebessége, akkor ugyanúgy csak pár másodpercnyi elmaradás lenne, úgyhgoy ez nem probléma.

na pontosan igy csinaljuk mi is. annyi hogy en nem allitok global readonlyt, de elveszem az ip cimet a slave-tol igy nem tudnak racsatlakozni se a kliensek

az ellenorzesre/ip cim allitgatasra irtam scriptet ami a 2 tuzfalon fut percenkent, fel perc eltolassal, igy az egyik kiesesekor is mukodik.

A'rpi

innobackupex?

Amúgy én próbáltam az mmm-e és nekem tetszett, jó volt, nem volt gondja. Mondjuk az olvasást máshogy kezeltem (ldirectord vagy mostanság keepalived)

Vagy lehet az is, hogy multi-masterként a keepalived (vagy a ldirectord) kezeli mind az írást, mind az olvasást.

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

( hrgy84 | 2013. 07. 16., k – 21:02 )

Replikacio kapcsan az MMM-mel mik a tapasztalatok? Raktam mar ossze demo kornyezetet, tetszett, napi szintu tapasztalatok erdekelnenek inkabb vele kapcsolatban.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( banyek | 2013. 07. 18., cs – 09:19 )

Ebben az esetben nem kell neked replikacio. Eleg az, ha a backupot, es a binlogokat biztos helyre teszed, mert barmikor tudsz akkor point in time recoveryt csinalni a mysqlbinlog utilityvel. Arrol nem is beszelve, hogy biztonsagosabb, mert ameddig a masik gepet amolyan hotbackupnak akarod hasznalni, egy elszaladt query azt is ki tudja csinalni.
Arra az egyre figyelj oda, hogy ha a backupot mysqldumppal csinalod xtrabackup helyett, akkor add meg neki a --single-transaction kapcsolot, hogy az egesz mentes folyamatot egy tranzakcio alatt hajtsa vegre. Ezzel ugyan felnyomod az egbe az undo space-t, de valoszinuleg nem fog gondot okozni.

+1, nem percekről van szó adott esetben, hanem egykét óráról is, főleg terhelés mellett. Én azt csinálom, hogy flush logs read lock, sleep, filerendszer szintű snapshot, és az adatbázias file szintű mentése a snapshotból, ami egy szabálytalanul leállított, de lockolt, és syncelt állapotnak felel meg, ami minimális kivételtől eltekintve tökéletesen működő szokott lenni. A replikációt is így szoktam helyreállítani dump helyett. Mondjuk ott utána mysqlcheck -A --repairt futtatok a biztonság kedvéért. Nálunk a többség tábla myisam.

Az a baj, hogy en --skip-lock-tables -sal vagyok kenytelen dumpolni, nem allhat meg az app...

A filerendszer szintun mar gondolkodtam en is, meg van irva a mysqlhotcopy alternativaja, de valamiert nem valt be (mar nem emlekszem, mi volt a problema, reszben a lock, reszben meg valami).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Miert igy csinalod?

1. lock
2. snapshot
3. unlock
4. masodpeldany inditasa a snapshotrol
5. dump a masodpeldanyrol
6. masodpeldany stop
7. snapshot destroy

Hol a problema?

Ill. latom, irod, h 1 lock sem lehet. Akkor miertnem dumpolsz a slave-rol.
Mindenesetre nem tudok elkepzelni realis esetet, h a dump idejere lehet lock, de a snapshot idejere nem.

t

Az a nagy büdös igazság, hogy atomi snapshot esetén (1 fájlrendszeren belül az LVM snapshotnak bizony atominak kell lennie) lock nélkül is működnie kell a dolognak. Legfeljebb rollbackelni fog a frissen beindított másodpéldány.
Ha pedig valaki elkezdi magyarázni, hogy neki ez nem működött, akkor gyorsan kezdjen el gondolkodni, hogy egy áramszünet/táphiba esetén honnan fogja elővenni a mentését, mert a hirtelen elmúló 220 sem fog előtte kérni egy lockot, és akkor az sem fog működni...

Nem a lock a lényeg, hanem a memóriában lévő táblák, változások lemezre írása (mindenféle app szintű bufferekből), és nem azért, hogy ne vesszen el adat, hanem, hogy a replikációt folytatni lehessen, pontosan attól az állapottól. Ezért:

FLUSH TABLES WITH READ LOCK
SHOW MASTER STATUS (ebből megvan a master pozicio)
sleep pár másodperc, (állítólag innodb a flush tables re se mindig írja ki egyből az adatot), snapshot, unlock tables, és a snapshot meg a master pozicio együtt alkalmas a replikáció indítására, és gyakorlatilag is szokott működni.

Szerintem amire én reagáltam, abban a setupban szó nem volt replikációról.

A feladat - ha jól értettem - az volt, hogy van egy darab, szingli adatbázis, amit le akarunk menteni.
Ha lock nélkül nyomunk egy snapshotot, az így készült állapot nem különbözik attól, mint amikor a gép alól kiesik az áram, majd újraindul.

Egyébként a replikáció sem változtat a helyzeten: lock nélkül is beindulni képes mentésnek kell készülnie a snapshotból. Természetesen ha valaki egy replikált masterről mentést csinál, majd arra valamikor később vissza akar állni, akkor a történet úgy indul, hogy minden más replikát a frissen visszaállított masterről újra kell inicializálni.

Értettem amit írtál, de mivel közben igencsak a replikációról is volt szó, úgy gondoltam kiegészítem, szerintem nem mondtam ellent. Az utolsó mondathoz annyit, hogy leállt master esetén nem feltétlen a mastert fogom indítani (és kukázni a slaveket), hanem az egyik slaveből lesz master és a mastert építem újra a slaveből. Ez azért lehet jó, mert a leállt masterről a slaveket csak akkor tudom újra építeni, ha előtte a mastert teljesen leellenőrzöm, elvégre a leállás okától függően lehet olyan sérülés, ami kifejezetten adatvesztéssel járt, ez ugyanis előfordulhat (igen, előfordulhat áramszünet esetén is). Ez az ellenőrzés, a leállás utáni indítással együtt már akkora kiesés, hogy célszerű lehet a korábbi slavet masternek kinevezni, hogy menjen tovább a rendszer.

célszerű lehet a korábbi slavet masternek kinevezni, hogy menjen tovább a rendszer.

Akkor végülis mi értelme van annak, hogy a mentett adatokban a replikáció "rendben legyen"? Szerintem ugyanis semmi. Ez egy baromság. A mentést csak akkor veszed elő, amikor már semmi más nem segít, már egyik slave sincs menthető állapotban. Akkor meg kit érdekel, hogy a visszatöltött mentés után az összes slave-et amúgy is újra kell inicializálni? Amit egyébként visszatöltés esetén sehogyse tudnál elkerülni, akármennyire "rendben van" a replikáció állapota a mentésben:
"hanem, hogy a replikációt folytatni lehessen"

Mert jelenleg nincs slave. Pont azert gondolkodok valamifele replikacion is, csak eleg sok irasom van, es nem tudom, mennyire lassit be. Van egy pocsek alkalmazasom, es app oldalrol nincs lehetoseg javitani rajta, azt kell uzemeltetni, ami van.

A masodpeldany inditasaval meg az a problemam, hogy ez egy Debian. Debiannal mig az inditaskori default mysqlcheck lefut egy 70G -s adatbazison, az nem rovid ido, es az I/O terhelest nem tudom meguszni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Hogy a kovetkezo upgrade esetleg visszairja? Vannak aggodalmaim e teren.

Nezd, megertem, hogy jot akarsz, es en is vegigzongoraztam mar ilyen lehetosegeket, sajnos azonban nem tudom igy megoldani a dolgot. A host osszesen 1G memoriaval rendelkezik (nem hasznalok memory ballooningot, rossz tapasztalataim vannak vele), egy ilyen szolid 50-70G -s tabla szinte tutira kiakasztana. Es a dumpnak is van I/O terhelese, akar van mysqlcheck akar nincsen. 100 MBites management halon meg nem biztos, hogy at akarom vonszolni, csak azert, hogy utana kidumpolhassam. Akkor mar inkabb a fajl szintu backup.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Magyarul szarbol akarsz varat epiteni? Akkor erdemesebb lenni az alapoktol kezdeni es nem faragni.

A slave-n a replikalas meg annyira lassit be, mint amennyire egyebkent is az iras...csak masik gepen. Nem latom a problemad.

> A masodpeldany inditasaval meg az a problemam, hogy ez egy Debian.

Mi koze ennek a debianhoz? A masodpeldanyt nem official init scripttel inditod, de legalabbis egy custom, altalad irt akarmilyen cucc: mysqld -S /tmp/mysql-backup.sock ......

> A host osszesen 1G memoriaval rendelkezik (nem hasznalok memory ballooningot, rossz tapasztalataim vannak vele),

Adjal neki tobbet. Ha nem tudsz, akkor a meretezessel alapveto problemak vannak.
Mellesleg ha nincs penz erre, akkor ne akarjon a megrendelo jobb szolgaltatast a semmiert.

Egyebkent ezt a problemat korberohogi az LXC vagy barmleyik masik container alapu virtualizacio.

tompos

- "a meretezessel alapveto problemak vannak": Nekem mondod?
- "A masodpeldanyt nem official init scripttel inditod": na ez az, amit inkabb szeretek elkerulni. Szivtam mar - mas szoftvernel - ilyesmivel, az epp eleg volt
- "Magyarul szarbol akarsz varat epiteni?": pontosan, es nem tudok (nincs lehetosegem ra) a gyokerekig lemenni. Sajnos azzal kell dolgozzak, ami van, max almodozhatok egy szep uj rendszerrol.

Nezd, nalad sokkal jobban tisztaban vagyok a mostani rendszer korlataival. Sajnos a korlatokat ledonteni nem tudom, a jelenlegi kereteken belul kell valamit csinalni. Lehet fikazni a mostnai kialakitast, csakhogy mindez nem az en erdemem, egy eve dolgozom itt, es probalok valami rend-felet kialakitani. Es en is rengeteget bosszankodom emiatt, meg almodok szep uj rendszereket, viszont akkor is a mostani rendszerbol kellene tovabblepni, es nem almokat kergetni. Nehez dolog ez, tudom, de nem mindig a konnyebb ut az egyszerubb.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Egyreszt:

> app oldalrol nincs lehetoseg javitani rajta, azt kell uzemeltetni, ami van

Itt HW-rol szo nincs.

OK, se HW-t nem lehet boviteni, se az alkalmazast nem modosithatod.
Ezen kivul meg peremfeltetel, h custom megoldasokkal nem foglalkozol (mint init script atirasa pl.).

De LVM vagy mas snapshot aware eszkoz nincs es nem is vagy hajlando arra atrakni a stuffot (a miert nem szamit).

Ezzel szemben:

> gondolkodok valamifele replikacion

Ezt akkor igy hogy? Ehhez is HW kell (pl.)

Nekem egyebkent tovabbra sem vilagos, miert allitod be a replikaciot es probalod ki, h mukodik v. nem, minthogy honapokig itt szenvedsz rajta?

tompos

Sorban megyek:
- Replikacio: pont azert gondolkodom rajta, mert egy masik virtualis gepen lenne hely + szerver, hogy be lehetne loni egy replikaciot, de a "minden backupnal rangassuk at a 100MBites halon a 70G-s adatbazist" irrealis. A masik virtualis gep nem ugyanazon a hoston van, mint a fo applikacio DB-je, es nem is tudom atmigralni.
- LVM: nincs helyem. Alaraknam bakker, istenbizony alaraknam, de ki van maxolva a disk a gepen. Lehet hogy ez az indok neked invalid, es nem szamit, nekem meg igen. Bocs.
- Azert nem allitom be a replikaciot es probalom ki, mert nincs hol tesztelnem a dolgot, es - masokkal ellentetben - en nem szeretek eles alkalmazas alatt adatbazisszervert elloni. Azert gyujtogetek adatot, mert nincs lehetosegem tesztelni, viszont a lehetosegekhez kepest fel akarom merni, hogy mekkora kockazatot vallalok azzal, ha kiprobalom.

Nem egy multicegnel / banknal vagyok, ahol ma leszolok a beszerzesnek, hogy legyszi holnapra harom szervert hozzatok, es ott van, hanem egy kis cegnel, ahol meg a virtualis gepek telepiteset is le kell fightolnom. Tudom, hogy egy idiota fasz vagyok, hogy ilyen helyre mentem dolgozni - de ez az en dontesem volt, es kiallok mellette. Igen, szukek a lehetosgeim, igen, nagyon le vagyok korlatozva - de ezt tudtam es vallaltam.

Hidd el, ha valamire en azt mondom, hogy nincs lehetosegem ra, akkor az nem egyenerteku azzal, hogy egy onfeju makacs ember vagyok, aki nem akarja a jot, hanem azt jelenti, hogy nincs lehetosegem ra. Tekintve, hogy van cegtitok is a vilagon, nem feltetlen osztom meg minden ilyesminek az indoklasat, ha nem feltetlen muszaj.

Probalhatunk innen konstruktivabb vizekre evezni, vagy elkonyveltel egy remenytelen idiotanak?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nem konyveltelek semminek.
Viszont ha egy forumon segitseget kersz masoktol, tiszteld meg oket azzal, h megosztod a korulmenyeket, plane ha erdekli oket.

A replikaciot nem kell az elesen kiprobalnod. Eloveszed a laptopod, beallitasz egy mysql instance-ot meg egy masikat (akar ket VM-ben, akar a laptopodon kivul) es elinditod, kinyirod, teszteled. Nincs koze az eleshez.

> LVM: nincs helyem

Ugyanannyi helyet foglal az adat az LVM-en es anelkul is.

> be lehetne loni egy replikaciot, de a "minden backupnal rangassuk at a 100MBites halon a 70G-s adatbazist" irrealis.

Errol szol a replikacio, nem kell atrangatnod mindent. Mi a problema...?

Szamomra meg tovabbra sem vilagos a felallas. Akkor most milyen backup van? Semmilyen?

t

Replikacio: az a baj, hogy terhelesmereshez pont nem igazan jo a laptopomon merni, mert nem fogok tudni valos korulmenyeket szimulalni. Nem a mysql replikacio beallitasaval van gondom, ha sokat nem is, de allitottam mar be ilyet, tudom, hogy hogy kell - a terhelesi vetuleteivel nincs tapasztalatom elsosorban.

LVM: Ugy ertem, az LVM VG-n nincs mar nagyon helyem. Ahol egyaltalan LVM van a virtualis gep alatt. Mert virtualis gepen belul sehol nem hasznalok LVM-et, ugyanis plusz hibalehetoseg

Jelenleg mysqldump van mindenutt, ami iszonyatos ideig fut ezen az egy DB-n, ezzel elhuzva a backup idoablakot, sok gep igy a ~ produktiv idoben kezd backupolodni, az ejszakai idopont helyett. Ezen a helyzeten szeretnek javitani, mert en eleve nem szeretem, ha egy eles gepen a backup valamikor reggel kilenc es deli tizenketto kozott kezodik meg. Es mivel sok helyen nincs innodb, igy maga a backup is meglatszik a terhelesen. Es sajnos a cucc ugy van megirva, hogy keveset tudok rajta parhuzamositani.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Igen, ezert kellene a dump-nak fenntartott helyet a VG-be raknod es akkor van hely a snapshot-nak. Bar azt eleve nem ertem, h miert nincs hely, hiszen azt allitod, sok az iras...es gondolom nemcsak update-ek.

snapshot -> backup az fs-rol -> snapshot destroy.

Persze ha nincs lvm, mert te nem szereted es ezert magad alatt vagod a fat, akkor elvagod magad a lehetosegektol. Meg nem szeretsz production geppel szarakodni, meg init scripttel meg semmive.

goto http://hup.hu/node/125549?comments_per_page=9999#comment-1624504

Szabad orszag, mindenki ugy hujiti magat meg generalja maganak a munkat, ahogy tetszik. Igy legalabb latszik, h mindig fut a backup job:)

tompos

Jelenleg ugy vannak a virtualis gepek megcsinalva, hogy a VM-ek diskjei LVM LV-ken vannak. A virtualis gepen belul azert nem szeretnek meg kulon LVM-et, mert egyreszt annak IO impactja van, masreszt nagyon megneheziti a FS host oldali felcsatolasat ha arra szukseg van (recovery), harmadreszt meg a dupla LVM-mel nagyon-nagyon rossz tapasztalataim vannak (erthetetlen kernelpanikok, etc), igy inkabb nem kiserleteznek vele.

Ellenben a VM-ek diskjei maguk is LVM LV-k, igy elvben a host oldalrol tudnek snapshotot csinalni, es - szinten elvben - maga a snapshot a COW miatt nem foglal helyet, viszont egyreszt ez nem oldja meg a 100 MBites halo problemajat, masreszrol pedig nem tudom, hogy amig tart a backup, addig mennyi iras jon a DB-be - es hogy arra van-e eleg hely. A VG merete nincs tulsagosan tultervezve.

Lehet hogy rosszul fogalmaztam egyebkent: nekem az LVM alapu snapshot az eles gepen no-go, mert ott egyreszt nem nagyon van hely, masreszt barmit akarok kezdeni a snapshottal, az a disk I/O impact miatt gazos. Ezert akarok replikat - azon lehet backupolni mar akarhogy, akar file alapon is, ott nem erdekes, ha disk terheles van.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

> viszont egyreszt ez nem oldja meg a 100 MBites halo problemajat

Hogyne oldana meg?
snapshot -> mount snapshot lv -> rsync a hostrol a backup szerverre -> umount -> snapshot remove

> amig tart a backup, addig mennyi iras jon a DB-be - es hogy arra van-e eleg hely

Ha annyi ido alatt nem fut le egy incrementalis rsync, akkor baszhatod.

> Lehet hogy rosszul fogalmaztam egyebkent: nekem az LVM alapu snapshot az eles gepen no-go, mert ott egyreszt nem nagyon van hely, masreszt barmit akarok kezdeni a snapshottal, az a disk I/O impact miatt gazos.

Az a legkevesbe gazos megoldas ebbol a szempontbol. Csak rovid, tervezheto idore szol es szabalyozhato eppenseggel pont a disk IO terheles.

> Ezert akarok replikat - azon lehet backupolni mar akarhogy, akar file alapon is, ott nem erdekes, ha disk terheles van.

Igen, ezt magyarazom, akkor miert nem csinalod? Belovod, elindul es kiderul... Egy master-slave replikacio a master iranyaba read-only. Sokat nem tudsz rontani, akarmennyit is benazol.

tompos

ui.: Meg mindig nem irtad le, pedig nagyon erdekel: milyen backup van _most_?

Jelenleg most a dump direktben halozaton at jon. Vagyis, van a backup szerveren egy script, ami ssh-n pubkeyjel belep a gepre, elnyomja a mysqldumpot a STDOUT-ra, es az a masik oldalon egy fajlba van iranyitva. Ez az, ami jelenleg baromi lassan dolgozik, mert maga a dump is lassu, plusz meg mindezt egy 100 MBites halon kell atvonszolni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A file szintu backuptol mindig azert felek, mert amennyire tudom, nincs garancia az adatformatum konstanssagara. Vagyis barmikor johet egy update, ami formatumot valt. Bar erre meg nem volt precedens, nem tudom, mennyire lehet ebben megbizni. Vegulis backuprol beszelgetunk.

De egyebkent pont ezert szeretnek replikat, mert ha az nem megy, akkor az nem erdekel senkit, de az eles db nem allhat le az rsync idejere, mert 70G az rengeteg. Ott meg lehetne mysqlhotcopyzni meg mysqldumpolni is akar.

Bar a replikacional meg felmerult bennem egy olyan, hogy ha all a slave, akkor hogy lehet utana ujra szinkronba hozni? Mert ugye ha tortenik iras a masteren, akkor a slave outdated lesz. Ha viszont csak lockolom a slavet, akkor viszont a master is lockolodik, hiszen a replikacio nem fut le (es myisamnal nincs row-lock csak table-lock).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

> A file szintu backuptol mindig azert felek, mert amennyire tudom, nincs garancia az adatformatum konstanssagara. Vagyis barmikor johet egy update, ami formatumot valt. Bar erre meg nem volt precedens, nem tudom, mennyire lehet ebben megbizni. Vegulis backuprol beszelgetunk.

Igen, ezzel en is igy vagyok.
Epp ezert utana mar az athuzott anyagrol csinalhatsz dumpot. Ha a dump jo, akkor megbizhatsz benne.
Hovatovabb akar csinalhatod, h ez naponta, es egy original pedig hetente v. havonta.

> De egyebkent pont ezert szeretnek replikat, mert ha az nem megy, akkor az nem erdekel senkit, de az eles db nem allhat le az rsync idejere, mert 70G az rengeteg. Ott meg lehetne mysqlhotcopyzni meg mysqldumpolni is akar.

Ertem en, h miert akarsz replikat, de lathatoan az akarat nem eleg, tenned is kellene erte:)
Megjegyzem, en faznek a replikarol backuptol.

> Bar a replikacional meg felmerult bennem egy olyan, hogy ha all a slave, akkor hogy lehet utana ujra szinkronba hozni? Mert ugye ha tortenik iras a masteren, akkor a slave outdated lesz. Ha viszont csak lockolom a slavet, akkor viszont a master is lockolodik, hiszen a replikacio nem fut le (es myisamnal nincs row-lock csak table-lock).

Elvileg megcsinalja magatol, a gyakorlatban nekem van 1 olyan replikam, ami vmiert nem akar. Az az egynel a master debian, lehet, h az a gond, vagy csak verziokulonbseg.
Mindenesetre igen, vhogy el kell kezdened a replikalast is, vagy epp javitanod idonkent: goto 1.

tompos

de mi tortenik, ha egyszeruen altereled a tablakat, hogy ne MyISAM tablak legyenek, hanem InnoDB-k? Vagy tolts vissza egy dumpot, ahol atirod sed-del.
Nem nagyon talalkoztam meg olyan alkalmazassal, amelyik myisammal mukodott, de innodb-vel nem. - Monjduk erre tudsz sajat laptopon tesztelni, mert ennek semmi koze nincs a teljesitmenyhez.

Az a baj, hogy az innodb-ban nincs meg egy az egyben nehany olyan feature-t, amit aktivan kihasznalunk a myisamban (maskepp van megcsinalva vagy egyaltalan nincs benne, mindenkepp plusz fejlesztest igenyelne). Nem tudom alterelni a tablakat, mert nem fut le az alter. A ket engine nem csereszabatos egymassal.

Ezen felul allitolag (ezt csak hallomasbol tudom, keretik a helyen kezelni) volt mar egy kiserlet innodb-re valo atallasra meg regebben, es drasztikus sebessegcsokkenest tapasztaltak. Nem tudom, mennyi ebbol az igaz.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

elso korben csinalj egy dumpot, ird at benne a MyISAM szavakat InnoDB-re, toltsd be a gepedre, es nezd meg az alkalmazast. Nehezen hiszem, hogy tenyleg ne lehetne atallni.
Milyen featureket hasznaltok, ami MyISAM specifikus?
A teljesitmenyvesztest el tudom kepzelni, de azt nem, hogy ne lehetett volna bekonfiguralni olyanra, hogy jo legyen. :/
http://www.mysqlperformanceblog.com/2009/01/12/should-you-move-from-myi…

mondjuk aki fulltext searchet akar nem kulso indexelon keresztul az meg is erdemli (Xaphian, Sphinx, Lucene) de mintha az 5.6-s mysql verzioban valamit okositottak rajta. (Ezt nem keresem ki)
A masikhoz viszont:
http://www.percona.com/files/presentations/percona-live/nyc-2011/Percon…
(20. oldal)

Az alter table-t azert tudom, mert konkretan probaltam, kivancsisagbol. Most fejbol meg nem mondom, mi az, amin elhasal, de van 2-3 tabla, ahol az alter table hibat ad vissza, es nem konvertalja at. A turmixot meg csak tejjel es gyumolccsel szeretjuk nem MySQL engine-kkel.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.