Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Data Recovery for MySQL Pödör István Webkonf 2011, Budapest 08 / Okt / 2011.

Hasonló előadás


Az előadások a következő témára: "Data Recovery for MySQL Pödör István Webkonf 2011, Budapest 08 / Okt / 2011."— Előadás másolata:

1 Data Recovery for MySQL Pödör István Webkonf 2011, Budapest 08 / Okt / 2011

2 Bemutatkozás Percona consultant InnoDB recovery lépésről lépésre Adatvisszaállítás kezdőknek :) Ha minden jól megy, mire vége, vissza tudsz állítani egy droppolt táblát

3 Az előadásról InnoDB adat visszaállítás Nem megyünk mélyen technikai részletekbe Ez helyett, inkább egy példa következik Bármikor nyugodtan kérdezzetek

4 Data set A példa adatbázis elérhető Table: `store` Összesen 2 sor van a táblában (az eredetihez képest a foreign key-t töröltem)

5 Néhány szükséges InnoDB info InnoDB nem táról táblákat, csak primary key indexeket A táblákat az index_id alapján különbözteti meg A táblákhoz tartozó azonosítót a data dictionary-ben tárólja (minden táblához tartozik két rejtett oszlop SYS_TABLES, SYS_INDEXES) InnoDB esetén az adat tárolás alapegysége a “page” ami 16kbyte.

6 Menetrend A táblákhoz tartozó ID-kat, a common table space- ből nyerjük ki (ibdata filet page-ekre bontjuk) Először a data dictionary táblákat állítjuk vissza Megkeressük a táblához tartozó index ID-t Definíciós file-t keszítünk a táblához Kiszedjük a file-okból az adatot Visszaállítás mysql-be

7 A tábla tartalma Mindössze ennyi:

8 A tool letöltése Miután letöltöttük, lekell fordítani: – https://code.launchpad.net/~percona-dev/percona-innodb- recovery-tool/trunk – Mindig a legutolsó változatot használd a trunk-ból A fordításhoz csak futtasd a “make” parancsot

9 Dobjuk el a táblát Semmi különleges, csak drop table

10 Mentsük ami menthető Amilyen gyorsan csak tudjuk, allitsuk le a mysql-t és készítsünk másolatot az ibdata file-ról

11 Hogy állunk most Tábla eldobva, mysql áll A recovery tool a ~/recovery/ könyvtárban van Az ibdata file pedig ~/recovery/ibdata_file

12 Futtassuk a page_parser-t Ha már leforgattuk a recovery tool-t, semmit sem kell tennünk page_parser szépen feldarabolja az ibdata file-t page-ekre, és sorba rendezi index_id alapján (InnoDB page signatures segitségével) Igy fog kinézni a könyvtár ahova ezt elvégzi 'pages-$current_timestamp' Innodb page-ek Primary Key ID alapjan lesznek köyvtárakba rendezve (tehát táblánként) pl: 'pages-$current_timestamp/FIL_PAGE_INDEX/0-91'

13 Így néz ki a page_parser A könyvtárunk pedig 'pages '

14 Elösször a SYS file-ok InnoDB nem táblákat, hanem indexeket tárol Ahhoz, hogy vissza állítsuk a táblát, kellenek az ID-k Ehhez először az InnoDB dictionary-t kell visszaállítanunk (SYS_TABLES, SYS_INDEXES), hogy megtudjuk az index_id-t SYS tables fixed és redundant row formatot használ (csak az érdekesség kedvéért) Akkor keressük meg a táblát amit eldobtunk

15 sys_tables és sys_indexes visszaállítása Mint mondtam ez azért kell, hogy megtaláljuk, hol vannak a store táblához tartozó page-ek Van két file az include/ könyvtárban – table_defs.h.SYS_INDEXES – table_defs.h.SYS_TABLES sys_tables mindig fix helyen van pages_xxx/FIL_PAGE_INDEX/0-1 sys_indexes ahogy az indexek is pages_xxx/FIL_PAGE_INDEX/0-3 (mindjárt világos lesz)

16 Get sys_tables list Kell egy symlink és ujra fordítás `cd include/; rm table_defs.h \ ln -s table_defs.h.SYS_TABLES table_defs.h` És a make …

17 Get sys_tables list Futtatjuk a contraint_parser-t. File format -4 (redundant) minden SYS táblához `./constraints_parser -4 -f pages /FIL_PAGE_INDEX/0-1/* | awk '/sakila\/store"/ && /SYS_TABLES/'` Az adatbázis `sakila` és keressük a 'SYS_TABLES' ID-t A tool kifog irni egy parancsot a visszaállításra, de ne foglakozz vele Mi a 3.oszlopban lévő számot keressük, 45

18 Get sys_indexes list Kell egy symlink és újra fordítás `cd include/; rm table_defs.h \ ln -s table_defs.h.SYS_INDEXES table_defs.h` És a make ujra …

19 Get sys_indexes list Megint contraint_parser File format -4 (redundant) minden SYS táblához `./constraints_parser -4 -f pages /FIL_PAGE_INDEX/0-3/* | awk '/45/ && /PRIMARY/'` A Primary index ID-t keressük a táblánkhoz Ismét kapsz parancsot a tool-tól a visszaállításhoz Nekünk a 3. oszlopban szereplő szám kell abbol a sorból, ahol a 3. oszlop értéke 45 97! A mágikus szám.. :)

20 Most egy kicsit nehezebb lépés Létre kell hoznunk a table_defs.h file-t a saját táblánkhoz table_defs.h gyakorlatilag a strukturát irja le C-ben a tool számára És azt, hogy mit kell keresnie

21 table_defs.h struktúra Szerencsére van egy tool ami segit elkészíteni a struktúrát Először a már létező table_defs.h linket kell törölni Majd hozzuk létre egy táblát ugyan azzal a struktúrával mint a droppolt tábla

22 Run create_defs.pl Ezután futtathatjuk a create_defs.pl scriptet és megoldja helyettünk

23 Run create_defs.pl Ahogy láthattuk, müködik. Legalábbis valamit csinált. Irányítsuk az outputot a table_defs.h helyére./include/table_defs.h Ezután ujra kell forgatni a tool-t (make)

24 Nezzük, hogy állunk most Ha “szerencsénk” van, a constraint_parser gond nélkül visszaállítja a tábla tartalmát Emlékezzünk a mágikus 97-es számra És csak emlékeztetőül a tábla tartalma:

25 Run contraints_parser Itt az ideje a contraints_parser-t valós adatra is futtatni A file format itt már compact! – -4 redundant – -5 compact És ami ebből lett, az eléggé hasonlít az eredeti adatra! :)

26 Visszaállítás Atirányítjuk a kimenetet... (~/recovery/default/store)

27 Visszaállítás Ezzel az adat kész is van a visszaállításra MySQL-nek hozzá kell férnie a file-hoz (Én átraktam a datadir-be /var/lib/mysql) Mivel a táblában eredetileg voltak foreign key-ek, ezért a tool által ajánlott REPLACE INTO nem fog működni. Szóval egyszerűen csak: `LOAD DATA INFILE '/var/lib/mysql/store' INTO TABLE store...` Lássuk mi történt..

28 Az eredmény

29 Gratulálok, ezennel megtanultad, hogyan kell visszaállítani a droppolt táblát! :) de...

30 Azért nem mindig ilyen egyszerű Ha a table space korrupt, a table_defs.h file némi tuningra szorul //néhány aproság// A table_defs.h ahogy említettem, a táblát és ezáltal az oszlopokat írja le Mindig lesz két rejtett mező

31 table_defs.h Egy timestamp és egy smallint(5) definíció így néz ki Amit tehetünk, hogy kicsit leszűkítjük a lehetőségeket

32 table_defs.h finomítása Ha ismerjük az adatot amit elvesztettünk, tudunk szűkiteni Ez a smallint(5) definition túlságosan is nagy! E szerint a minimum 0, és a maximum kb. 65k uint_min_val: 0, uint_max_val: De emlékszünk, hogy nekünk a legkisebb érték 1 a legnagyobb pedig 2 volt (persze általában ennél azért nagyobb a szorás) Átírhatjuk egy kicsit: uint_min_val: 1, uint_max_val: 10 A timestamp oszlophoz bártran beállítatjuk a HAVE_LIMITS = TRUE És így tovább, ehhez már azért kell ismerni a típusokat picit.

33 File_per_table esetén Ha file_per_table opcióval droppoljuk a táblát, akkor innodb törölni fogja a diskről. Ilyenkor a block device- ra kell futtatni a page parsert (ez már tényleg nem egyszerű)./page_parser -f /dev/sda Ha az ibd file megvan, csak néhány sor lett törölve – Futtassuk a page_parsert az ibd file-on – Keressük meg a könyvtárat a legkisebb ID val. (pl. pages_xxx/FIL_PAGE_INDEX/0-15) – És már is lehet ismételni a korábbi lépéseket

34 Kérdések, kommentek ? Nem mindig könnyű Ettől függetlenül, megéri gyakorolni Töltsd le a slide-ot (percona.com) és próbáld ki Könnyü kérdésekkel, küldj t. – istvan.podor at percona.com – // – // https://launchpad.net/percona-innodb-recovery-toolhttps://launchpad.net/percona-innodb-recovery-tool


Letölteni ppt "Data Recovery for MySQL Pödör István Webkonf 2011, Budapest 08 / Okt / 2011."

Hasonló előadás


Google Hirdetések