mysql adatbázis visszaállítása

Debian GNU/Linux

Van egy gondom, hogy lenny alatt 5.0.5-s mysql adatbázist kellene upgradelni 5.5.32-re.
A gond az, hogy az adatbázis megvan de a rendszer már nincs, s a mysl-be elmentett adatokat kellene átvinni az új rendszer alá. Esetleg valakinek valami ötlete van-e?

  • 11036 megtekintés

( tovis v | 2013. 09. 07., szo – 13:25 )

Én óvatos duhaj vagyok! Nem tudom milyen értéket képvisel és mekkora is ez az adatbázis.
Megbízhatóan, mindig a szöveges "dump" volt jó export/import adat.
"Felcsapni" egy minimális Debian Lenny -t ck 2 óra (ha nincs extra hardwer probléma és van stabil internet kapcsolat) akkor simán tudsz telepíteni egy megfelelő verziójú MySQL -t, ott binárisan beépíteni az adatbázist, és dump - ezzel már biztos megtudod oldani a helyreállítást.

Egy próbát persze a bináris "betöltés" is megér:
Bölcs ha az aktuális adatbázist mented, mielőtt machinálsz.
MySQl leállít, a megfelelő helyre az adatbázis (/var/lib/mysql) bemásol és újra indít mysql - logot jól megnézni!

* Én egy indián vagyok. Minden indián hazudik.

Úgy érted, dump helyett mire jó?
Vagy mire gondolsz?
Dump (ha csak minimálisan hasonlít az oracle exp/imp működésére) nem igazán jó backupnak, mert lassabban lehet belőle helyreállítani az adatbázist, mint a fájlok mentésével.
MySQL-hez úgy tudom, nincs rman jellegű backup megoldás.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Igen, úgy értem, hogy dump helyett mire jó.
Pont ezek a bajaim - a dump nem verziófüggő, a dump visszatöltése újragenerálja az indexeket (indexhibák ellen kitűnő megoldás). Csupán a mappa lementése nem fogja megoldani pl. az inkonzisztecia problémákat, sőt, elő sem fognak jönni, és hamis biztonságérzetet ad.
Ha meg binális logokat használsz (tranzakciós logok), és nem áll a mysql-ed, amikor lemented, még adatvesztésed is lesz. Dump meg mehet online is.
Szóval konkrétan mire jó, ha nem használok dumpot, és lementem a mappákat?
--
PtY - www.onlinedemo.hu

MySQL-lel nincs sok tapasztalatom, szóval nem mernék szakérteni.
Az biztos, hogy dump-ból helyreállítani egy nagy adatbázist, k. lassú.
A dump normálisan nem a napi backup kiváltására való.
Archiválásra, adatmozgatásra egyik szerverről a másikra igen, kis méretű adatbázisok esetén talán mentés helyett is, de egyébként... A mentés tervezésekor nem árt számolni egy esetleges helyreállítás idejével is.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

7*24-ben futó mysql-t lvm-re illik pakolni, flush tables with read lock, lvm snapshot kreálás, unlock tables, aztán a snapshot már menthető, a binlogokat meg szépen rá lehet utána pakolni, ha köll. Ilyen környezetben a visszaállítás időigényét is le kell szorítani, arra meg szerintem pont nem a szöveges dump/restore a legjobb megoldás.

Ma sz@r az index, arra nem hiszem, hogy a DB teljes újraépítése a megoldás :-) El lehet dobni, újra lehet kreálni, akár menet közben is, nem?

Ok, ez valóban mind igaz, de verzióprobléma akkor is fennáll.
Egy olyan helyzetben, mint a threadindító, pont ezt okozza: telepítened kell egy kompatibilis rendszert, azon upgrade-elni, majd átemelni az új környezetbe, vagy azon dumpolni, és az új rendszerben meg importálni. Ilyen esetekben űber nagy szívás. Kis méretű (pl. webes) adatbázisoknál is, nem csak nagyoknál.
Ha meg nincs lvm, akkor snapshotolni sem tudsz.
--
PtY - www.onlinedemo.hu

Verzióprobléma bármilyen mentésnek a frissebb sw-be történő visszalapátolása során adódhat, db esetében persze komolyabb a gond, hiszen nincs olyan tool, ami a bináris db-fájlokat képes lenne átmókolni az egyes verziók között - holott létezhetne. Láttam már jogszabályi kötelezettség miatt megőrzött őskövület hw-eket, amik csak a helyet foglalták, meg a port fogták, de az azokkal feldolgozott adatokat még x évig helyre kell tudni állítani, és ez volt a legegyszerűbb megoldás - itt is ez a helyzet: a régi mentés értelmezéséhez kell egy régi sw.

A topic indítójának a problémáját szerintem az okozza, hogy ugyanolyan formátumban készült a db archiválása, mint a rendszeres mentése, és most egy ilyen archivból kell visszaállni, ami tényleg méretes szívás. Vagy meg kell őrizni az archívok megőrzési idejének megfelelően visszamenőlegesen a sw-környezetet is, vagy formátumfüggetlenül kell archiválni.

Ha nincs lvm, akkor az valóban szívás - másik oldalról viszont a rendszer összerakásánál elkövetett orbitális hiba.

Kár, hogy a virtualizált környezet nem minden esetben működik.
Ahol törvényi előírások miatt őrizgetnek őskövületeket, ott általában nem a tudatlanság az ok.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Nem biztos, hogy van olyan virtuális környezeted, ahol egy sparkot tudsz virtualizálni, vagy van valami spec hw kulcs, ok. Viszont sok esetben x86-ot őrizgetnek, aminek semmi értelme nem kéne, hogy legyen. Egy windows nt 3.x-et is be lehet virtualizálni.
Megkockáztatnám, hogy egy netware 3.1-est is.
--
PtY - www.onlinedemo.hu

Én speciel VAX-ra emlékeztem, amit még tíz (de lehet, hogy húsz) éves korában is őrizgettünk, mert azon volt az archivum. És a spéci hardver (WORM diszkek) miatt akkor sem lett volna esély virtualizálni, ha történetesen ismertük volna a linuxos VAX emulátort. :)

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Oké, virtualizálj be például Alpha procin futó OS-t meg adatbáziskezelőt :-P De mondhatnék olyat, hogy SCO Unix-on fut(ott), és hw-kulcsos alkalmazás... Esetleg AIX 4.2-4.3-on mocorgó SAP, valami 7.x-es Oracle DB-vel maga alatt - olyan helyen, ahol ez az utolsó RISC motyó, csak PC van már hosszú évek óta...

Azért keress rá a MySQL online backup kifejezésre! ;)
(bár lehet, hogy az már fizetős, mert mintha clusteres doksiban láttam volna... :( )
Egyébként meg ha jól veszem ki a szavaidból, az üzemeltetéssel lehetnek gondjaid. Az upgrade-ek általában nem úgy történnek, hogy volt egy rendszerem, gyártok egy újat, a régit eldobom, majd az újon próbálom valahogy összehozni az adatbázist az új verzióra.

Az LVM snapshot meg... No arra nem bíznék adatbázist, ha nem feltétlenül muszáj. Ugyan nem látom át teljesen sem a snapshot működését, sem a mysql-ét, de én tartanék némi adatbázis sérüléstől, inkonzisztenciától, ha az adatbázistól független alkatrészekre alapoznám a backupot.
Amíg egy LV-n van a teljes adatbázis, még so so... De ha több helyre van szétszórva?

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ööööö, izé - nem nekem van problémám :)
Esetemben nem tudunk beszélni olyan méretű adatbázisról, ahol 24 óra ne lenne elég egy dumpból való visszatöltésre - hogy ez szerencse-e, vagy átok, azt passzolom.
Én a topikindítóból azt vettem ki, hogy pl. anno a mysql adatbázis külön disken volt a rendszertől, és azt eltették, a rendszer azóta a tűz martaléka lett (akár metaforikusan is). A DB megvan, és életet kell bele lehelni, de ahová visszatennék, az már újabb mysql, és bele kéne integrálni.
Amit fentebb az upgrade-ről írtam, erre a scenariora vonatkozik, így kell érteni.
Upgrade-elni amúgy is tesztkörnyezeten szoktam előbb, ha kell ilyesmit csinálni.

Az LVM kérdésbe nem szólnék bele, nem használok célzottan lvm-et ilyen célra, de a snapshot logikusnak tűnik - bár, ha eddig kell fajulnia a dolognak, akkor VM snapsot, és azt mentjük.
--
PtY - www.onlinedemo.hu

Az LVM-snapshot teljesen jó. Eléggé alaposan gyúrt db, 7*24-ben kell, hogy menjen, ergo aktív-passzív fürt, alkalmazás felváltva olvas a két db-ből, írni csak egy helyre ír (a replika késleltetése belefér, illetve van rá megoldás az alkalmazásban). Slave alatt széthullott a RAID-tömb, vagy "csak" elhasalt/szétcsúszott a replikáció.
Slave-et a replikáció lelövése után az lvm-es snapshotból rsync-kelve, majd a binlogot rátolva tökéletesen ment tovább az élet... Nem, nem egyszer, hanem sajnos egy raid-kontroller kontra ssd összeférhetetlenség miatt jópár alkalommal tesztelve. Úgyhogy az LVM-es snapshot-tól nem kell félni - szerintem...

"dump visszatöltése újragenerálja az indexeket"

Ettol lesz jo lassu.

"Ha meg binális logokat használsz (tranzakciós logok), és nem áll a mysql-ed, amikor lemented, még adatvesztésed is lesz."

Akkor nem, ha egy sessionben 'FLUSH TABLES WITH READ LOCK' -ot tolsz, meg asszem van a binaris logok flusholesere is van parancs. Nyilvan a shell script teljesen alkalmatlan erre a feladatra, de valami masik scriptnyelv, amiben nyitva lehet egy SQL kapcsolatot tartani (PHP, Perl, Python, Ruby) teljesen alkalmas az ilyesmire.
-- 

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

Nem (csak) ettől lassú. Újraépíti az egész adatbázist, ha nem tévedek. Magyarán amikor egy dump-ból töltesz vissza, akkor minden egyes sorra kiad egy-egy insertet.
Egyébként nem tudom, mysql-ben tiltható-e az index, ha igen, akkor a dump betöltésének idejére célszerű ezeket letiltani és újragyártani őket a betöltés után.
"Némileg" gyorsabb szokott lenni (oracle és DEC Rdb esetében tesztelve :) )

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

"minden egyes sorra kiad egy-egy insertet."

Ha nem hasznaltal --extended-insert kapcsolot, akkor igen. Ha hasznaltal, akkor jo nagy adagokban tolja be a sorokat, tobbszaz sort egy-egy inserttel.

Tilthato az index. tiltja is. De a tabla betoltese utan kiadja rogton az index ujrakalkulalasara a parancsot a dump maga.
Egyebkent meg mindegy, mikor lesz kurva lassu a gep. Maga az index ujrageneralas egy 20-30G -s tablanal _nagyon_ sok tud lenni.
-- 

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

Nem, nem mindegy.
Ha aktív indexeid vannak és abba szúrsz be új sorokat, az nagyságrendekkel lehet lassúbb, mint ha egy index nélküli táblát írsz és azt indexeled.
(még mindig: én csak Oracle-t és Rdb-t láttam nagy adatbázissal, csak arra alapozva írom)

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

"Ha meg binális logokat használsz (tranzakciós logok), és nem áll a mysql-ed, amikor lemented, még adatvesztésed is lesz."

Ezt tudná valaki indokolni?
Mert eddig úgy tudtam, ezek a logok (a'la Oracle RDBMS redo logs) arra valók, hogy megakadályozzák az adatvesztést, illetve, hogy konzisztens maradjon az adatbázis(*).
Őket közvetlenül nem kell (nem szabad/illik) menteni, de épp ezek biztosíthatják, hogy képes legyél online backupot futtatni.
Legalábbis átfutva a mysql doksijának erről szóló részén, nekem ez jött le. Akkor mi itt az igazság?

* - kissé már bizonytalan vagyok, évekkel ezelőtt láttam utoljára éles szervert, k.sokat felejtettem. :(

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ez teljesen így van, és pont ezért van az, hogy az adatfájlok másolása menet közben nem ajánlott addig, amíg ezek a logok nincsenek belegyúrva az adatbázisba, mert az csak ezekkel együtt konzisztens.
A különböző Oracle által támogatott backup toolokat ez a probléma nem érinti.
--
PtY - www.onlinedemo.hu

Oracle esetében ez úgy működik, hogy az épp mentés alatt álló táblateret backup módba teszem, másolom, backup mód kikapcs.
Köv. táblatér, goto 1, míg végig nem értem mindegyiken.
Eközben ezekben a logokban gyűlnek a változások, ha valamelyik megtelik, akkor megy archivumba és keletkezik egy üres.

Szóval oracle alatt ehhez még spec. tool sem kell.
Ezért értetlenkedtem.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Félreértés: a MySQL az Oracle terméke - így értettem az Oracle által támogatott toolt.
Vélhetően működik, amit írsz, csak ha van valami tényleges bug-od, és nem tudod visszatölteni emiatt az adatokat, akkor a support el fog hajtani, mert nem rman-nal mentettél.
--
PtY - www.onlinedemo.hu

Tudom, hogy az oracle tulajdonában van.

Egyébként megtörtént, nem hajtott el.
Csak két hétig szopattam az indiai gyereket, mire rájöttem, hogy én keféltem el valamit. Mert neki nem tűnt fel. :D

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Nem mázli, szívás. Ha elhajtanak, akkor valószínűleg nem várom tőlük a választ, hanem tovább nézegetem, hogy mivel van gond és akkor két héttel hamarabb végeztem volna egy munkával.
A 1st levelt nem igazán tudom értelmezni.
Náunk nem volt, Oracle-nél meg... én a metalinken jeleztem, hogy gáz van, ők válaszoltak, levelezgettünk egy darabig és a végén szóltam, hogy inkább hagyja a fenébe, megoldottam. :D
De hogy különböző szintű supportjuk lett volna, arról nem tudok.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Oracle esetében nem tudok mit kezdeni a 1st level témával. :)
Különösen az említett társalgást követően.
Annyira nem értette, hogy mi van és volt náluk ilyen, hogy 1st, 2nd, 3rd level, akkor miért nem lökte tovább?

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

( banyek | 2013. 09. 07., szo – 16:47 )

Milyen adatbazis, InnoDB vagy MyISAM?

5.0-s mysqlt tudsz letolteni, az ala be tudod huzni az adatokat (Bemasolod a mysql datadir ala) onnan tudsz csinalni mysqldumppal dumpot, vagy felupgradeled 5.5-re, majd megint atmasolod az adatokat, etc.
http://dev.mysql.com/downloads/mysql/5.0.html

( Dwokfur v | 2013. 09. 07., szo – 17:15 )

Gentoo mysql upgrade-re van szerintem hasznos step-by-step guide. Persze a gentoo specifikus részeket át kell ugrani. A parancssori paraméterekhez meríthetsz ötleteket. Meg ugye neked csak a fájl-ok vannak meg. Ha azokat bekopizod, akkor szerintem meg lehet csinálni.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( tompos v | 2013. 09. 07., szo – 19:59 )

Atmasolof a mysql datadir-t majd lejetszod az upgrade-soran levo teendoket. Ha mindenigaz nem tobb, mint a mysql_upgrade futtatasa.

tompos

A topik kapcsán belenéztem valami doksiba, ott azt írták, hogy upgrade-kor nem szabad(???) kihagyni a fő verziókat.
Csak az nem volt tiszta, hogy 5.0 -> 5.5 közti három vagy négy verzió "fő"-nek számít-e vagy sem. Mert mintha épp azzal példálództak volna, hogy 5.0-ról előbb 5.1-re stb.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Csak arra céloztam volna (már amennyire értem, hogy mit írsz :D), hogy ha van egy 5.0-s adatbázis és egy 5.5-ös szerver hozzá, ott elég esélytelen az upgrade, amennyiben valóban meg kell lépni az 5.0->5.1->5.x->5.5 sort.
-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Nem tudom, ezt direkt csináljátok?
Mondom: "amennyiben meg kell lépni a..."!!!
Ahogy előtte azt is említettem, hogy nem teljesen tiszta, mit értettek főverzió alatt x.n-ből az x vagy az n számít "fő"-nek? Ha jól értelek, akkor az x, ahogy az normálisan elvárható.

-----------------------------------------
Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

MySQL 4-rol 5-re volt egy binaris formatum valtas, azert mondjak azt, hogy nem szabad kihagyni a kozbeeso verziokat.

Azota egy dolog tortent, maga a mysql nevu adatbazis bovult ki asszem 3 uj tablaval, a mysql_upgrade gyakorlatilag ezeket a tablakat potolja.

Egyebkent meg van mentes a dologrol, egy probat meger, nem?
-- 

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

( tovis v | 2013. 09. 11., sze – 17:25 )

OFF: Ez is egy nagyon tanulságos és hasznos téma.
Kismillió hozzászólás, egyik bölcsebb mint a másik. Aki viszont feldobta, eltűnt!?
Mi lett a megoldás?

* Én egy indián vagyok. Minden indián hazudik.