InnoDB táblák helyreállítása

Adatbázis: SQL, XML DB

Van egy szerver, amiről a mysql állományokat sikerült megmenteni. Egy szűz linuxon felraktam egy mysql szervert és oda raktam át a mysql állományokat. A MyISAM táblákkal nincs is baj, egyszerű bemásolás után működnek. Viszont az InnoDB táblákat nemlétezőnek deklarálja lekérdezéskor (látja, hogy ott vannak, de nem tudja lekérdezni). Annak ellenére sem, hogy a MySQL rendszeradatbázis táblái is helyre vannak állítva.

  • 5623 megtekintés

( miloska | 2011. 04. 10., v – 16:16 )

Logban kicsit tobb info?

Nekem akkor volt ilyenem ha valamelyik innodb specifiku beallitas nem egyezett meg az eredeti geppel. Ha megvan az eredeti my.cnf probald azzal elinditani.

( vl v | 2011. 04. 10., v – 17:09 )

Az egész datadir tartalma megvan? az ibdata meg az ib_logfile is? Azok nélkül nem fog menni.
Ezen felül nem árt, ha pont ugyanolyan, vagy legalábbis ugyanolyan major.minor verziójú binárissal próbálkozol, ill. ha el voltak tekergetve az innodb paraméterei a my.cnf-ben, akkor azok közül is kellhetnek egyesek.

( Hnorbi | 2013. 12. 11., sze – 19:10 )

Szervusztok!

Előélet:
Márciusban fel lett telepítve egy Windowsos szerver, MySQL-llel.

Most "le lett mentve", és újrahúzták, majd a nyakamba sózták/megörököltem a MySQL-t.

A lementés a Data könyvtár kimásolását takarta (valszeg futó mysql alatt) (+konfig fájl)

Feltettem egy MySQL-t (közel azonos verziót, mint ami fent lehetett)
Kicseréltem a data könyvtárat. (és a konfigfájlból is a régit használtam)

Elindul az adatbázis, viszont (pár) InnoDB-s tábla tök üres. Ezekben lennének állítólag az adatok.

innodb_force_recovery=2
innodb_force_recovery=3
innodb_force_recovery=6
-ot próbáltam eddig.

Milyen varázsigével lehetne kicsalni az adatokat? Vagy nevezzük reménytelennek?

Köszi
Norbi

U.I.: A sorok között kiolvasható, hogy a szerver üzemeltetője nem sok dolgot backupolt

Én a replikáció kapcsán szoktam ideoda ilyen adat mappákat másolgatni, az innodb ezt nem túl jól tolerálja, de a logban mindig valami konkrét hiba van, hogy mi a baja velük. Szerintem ha eddig nem nézted, vagy nem tudtál vele mit csinálni, akkor ezt meg kéne nézni, vagy másold be, ha érdekesnek tűnik.

"The log sequence numbers 30387090 and 30387090 in ibdata files do not match the log sequence number 30387100 in the ib_logfiles"
Gondolom ib_log file-ok is at lettek masolva, de mas a merete mint ami mostani mysql konfigban meg van adva, bar azt irja elkezdte helyreallitani, kerdes igy sikerul-e neki (lehet csak meg kellene varni).

Igaz, atsiklottam felette pontosan mit is mond, nem azt mondja hogy elter a meret csak elter a szamozas attol ahol adatok szerint kellene tartania, mert nem rendesen lett leallitva, ezert nekiall a logokbol helyreallitani, szoval jo esellyel csak turelmesnek kell lenned. Talan idonkent irogatja is logba hol tart a helyreallitas.

Nekem amikor ilyet írt le is állt a mysql szerver :D Úgyhogy arra kár várni.

Meg kéne nézni van-e olyan file amit a mysql újra tud csinálni, de ha létezik, és hibás, akkor az hibát okoz. Pl. az innodb logfile átméretezésénél is (configban átírás után) törölni kell a az innodb tranzakcio log fileokat (persze leállított állapotban) és utána helyesen hozza létre őket, ha léteznek rossz méretben, akkor viszont el sem indul. Esetleg valami ilyesmi. (természetesen a törlést úgy értem, hogy áthelyezés, másolat stb.stb.)

Valóban... Nem állított helyre semmit.

Ha recovery 6-ttal indítom:

[Warning] InnoDB: Allocated tablespace 21, old maximum was 0

valamint:

[ERROR] InnoDB: Failed to find tablespace for table ... in the cache. Attempting to load the tablespace with space id 36.

üzenetekkel találkozom csak.

Most épp 20 perce áll le.

Linuxra áttettem

nem teljesen ugyanaz a mysql verzió :S

Dec 16 21:04:45 moon mysqld: InnoDB: Database page corruption on disk or a failed
Dec 16 21:04:45 moon mysqld: InnoDB: file read of page 5.
Dec 16 21:04:45 moon mysqld: InnoDB: You may have to recover from a backup.
Dec 16 21:04:45 moon mysqld: 131216 21:04:45 InnoDB: Page dump in ascii and hex (16384 bytes):
...
Dec 16 21:04:46 moon mysqld: InnoDB: End of page dump
Dec 16 21:04:46 moon mysqld: 131216 21:04:46 InnoDB: Page checksum 2711061147, prior-to-4.0.14-form checksum 3360127607
Dec 16 21:04:46 moon mysqld: InnoDB: stored checksum 3379427339, prior-to-4.0.14-form stored checksum 3379427339
Dec 16 21:04:46 moon mysqld: InnoDB: Page lsn 0 30382269, low 4 bytes of lsn at page end 30382269
Dec 16 21:04:46 moon mysqld: InnoDB: Page number (if stored to page already) 7,
Dec 16 21:04:46 moon mysqld: InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
Dec 16 21:04:46 moon mysqld: InnoDB: Page may be a system page
Dec 16 21:04:46 moon mysqld: InnoDB: Database page corruption on disk or a failed
Dec 16 21:04:46 moon mysqld: InnoDB: file read of page 7.
Dec 16 21:04:46 moon mysqld: InnoDB: You may have to recover from a backup.
Dec 16 21:04:46 moon mysqld: InnoDB: It is also possible that your operating
Dec 16 21:04:46 moon mysqld: InnoDB: system has corrupted its own file cache
Dec 16 21:04:46 moon mysqld: InnoDB: and rebooting your computer removes the
Dec 16 21:04:46 moon mysqld: InnoDB: error.
Dec 16 21:04:46 moon mysqld: InnoDB: If the corrupt page is an index page
Dec 16 21:04:46 moon mysqld: InnoDB: you can also try to fix the corruption
Dec 16 21:04:46 moon mysqld: InnoDB: by dumping, dropping, and reimporting
Dec 16 21:04:46 moon mysqld: InnoDB: the corrupt table. You can use CHECK
Dec 16 21:04:46 moon mysqld: InnoDB: TABLE to scan your table for corruption.
Dec 16 21:04:46 moon mysqld: InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
Dec 16 21:04:46 moon mysqld: InnoDB: about forcing recovery.
Dec 16 21:04:46 moon mysqld: InnoDB: Database page corruption on disk or a failed
Dec 16 21:04:46 moon mysqld: InnoDB: file read of page 2.
Dec 16 21:04:46 moon mysqld: InnoDB: You may have to recover from a backup.
Dec 16 21:04:46 moon mysqld: 131216 21:04:46 InnoDB: Page dump in ascii and hex (16384 bytes):
...

:) Zseniális, hogy végül megoldották. Végülis jobb későn mint soha. Eddig úgy néz ki inkább mariadb 10 lesz a következő 5.5 helyett (abból msot vegyes mariadb és mysql), nem tudom ez van e mariadbben. Mondjuk a configot nem kell sűrűn változtatni, szóval annyira nem volt vészes, de elég bosszantó ilyeneken elakadni. Mondjuk honnan tudná, hogy a file méret a rossz, vagy a config? Gondolom ezért van (volt) így.

( kicca | 2013. 12. 11., sze – 22:27 )

nekem volt hogy ful szethalt minden viszon ibd fileok megoltak meg.

legegyszerubben a kovetkezokepp lehet visszallitani:
1) csinalni kell egy ures mysql instancet (nem fontos de egyszeruseg kedveert)
2) meg kell csinalni dbt
3) letre kell hozni tablat
4) ALTER TABLE `tablaneve` DISCARD TABLESPACE;
5) hexeditorral meg kell nyitni ibd-t.
eredeti: http://kepfeltoltes.hu/131211/ibd_from_www.kepfeltoltes.hu_.png
0x22-0x25 ig es
0x26-0x29 ig meg kell editolni sorszamat tablanak.
Mivel uj mysql instance es uj tabla ezert az uj szam 1 lesz.
uj: http://kepfeltoltes.hu/131211/ibd_to_www.kepfeltoltes.hu_.png
6) be kell masolni a var lib mysqlben a megfelelo helyre a modositott adatot
7) ALTER TABLE `tablaneve` IMPORT TABLESPACE;
8) le kell allitani mysqlt, majd el kell inditani force recovery = 6 al
9) dump tabla.

szerk: a kurva eletbe most latom, hogy thread necromancy lapot megint kijatszotta vki