Mysql - как да възстановите базата данни от

MySQL база данни, състояща се от InnoDB таблици - нещо добро. Но това може да се превърне в източник на сериозни проблеми, ако един ден "падне" на сървъра, както и ще бъдат на разположение свежи резервни копия. В случай на MyISAM таблици - просто копирайте файловете от базата данни изгубени в нова празна база данни. С такава насоченост InnoDB, уви, не мине. Но възстановяването, обаче, е почти винаги е възможно. Да започваме.

Най-малкото, което трябва да се възстанови - файлове и .ibd * .frm navernuvsheysya от база данни MySQL. 2 файла трябва да бъде на всяка маса. Ако не сте ги намерили в старата база данни - всичко е много тъжно. Най-вероятно, това означава, че данните на всички маси, съхранявани в един и същи файл, но това е друга история. В този случай остава да съчувстваме и посъветва за в бъдеще, не забравяйте да зададете един много полезен параметър в настройките на MySQL:

[Mysql]
innodb_file_per_table = 1

Е, ако * * .frm .ibd и е установено, - макар че възстановяването ще бъде малко по-досаден процес, но е вероятно да бъде завършен успешно. В първия експеримент, много ми помогнаха тук това (1), както и че (2) статия, обаче, аз трябваше да отида по различни пътища.

За да започнете, изберете нов MySQL сървър, за предпочитане една и съща версия, че е бил в засегнатата базата данни. Знайте версията, можете, например, от базата данни на лог файл. Версия на операционната система, като цяло, не е важно. Но под Unix има повече от някакви лосиони. Във всеки случай, ние силно препоръчваме да не използвате работи MySQL сървър, в резултат на последващи шамански действия той може да бъде предмет, както и проблеми, просто само се увеличават. Под Windows, начина, по който всичко мина добре и обслужване Денвър, както и всички команди могат да се изпълняват от неговия PhpMyAdmin. Но когато възстановите InnoDB Percona сървър, не остава нищо друго, как да се изгради сървър, работещ под Unix.

Да вървим. Да не забравяме innodb_file_per_table = 1 в опции, създаване на база данни със същото име като на жертвата. Създайте таблица в нея, с вашето име й възстановени:
Създаване на таблица `sometable` (` id` INT първичен ключ) ДВИГАТЕЛ = InnoDB;

Сега ние се спре MySQL, замества го в .frm подаде старата ни от масата, и .ibd да копира себе си "за експериментите." Изпълнете MySQL, и изпълни SHOW TABLE `sometable`;

Ура! Сега имаме структурата на починалия маса! И в първия от връзките тя твърди, че без него, нищо, за да се възстанови. Сега можете да се (да не забравяме копирането спира MySQL) се опита да замени нашата .ibd файл с данни. Ние се опитваме да извърши избор и. с трясък на сървъра се срива. За да се разбере какво се случва, погледнете неговия дневник: "Id маса sometable такъв, но трябва да бъде такъв и такъв!". Това е основната тъга. съхранява в базата данни на всяка маса идентификация и да я проверки (това се съхраняват във файлове .ibd).

Сега имате 2 начина да се сприятеляват със стария маса ID и идентификатор в новата база данни. Един от вариантите - да замени идентификатор в самата база данни. Е, ако щете - това е добре. Pomos това май за комунални услуги, която работи Unix пее от тук. Аз го компилира успешно, но когато се опитате да ./ibdconnect -o / ЮЕсАр / местни / MySQL / ibdata1 -f / ЮЕсАр / местни / MySQL / someDB / sometable.ibd -d someDB -t sometable уви, фокусът не се предава. Тя правилно посочи номер, но пише за грешка, когато се опитате да го промените. Е, това може да бъде само преди създаването на нова таблица за приключване противодействие на новата база данни, така че да съвпада с генерирания масата. За да направите това, трябва само да се създаде скрипт, премахване на масата, как да го направя - е в първата справка. Ако имате много маси - по-добре първо да се намери таблицата с минималната самоличност. За да нулирате брояча на сървъра MySQL - трябва да създадете базата данни, и може да се наложи да премахнете 3 иб * файл.

прескачане-innodb_checksums = 1
innodb_force_recovery = 5

Ако таблицата е отворен - спешно да го спаси. ) Но ако на масата беше страхотно - всичко ще си дойде от предишната грешка. Въпроси, които този номер във файл може да се повтори няколко пъти, в началото на всяка вътрешна страница. Така че ние ще трябва да се ходи внимателно претърси файл, промяна на идентификатора, където номер и той наистина не е докоснете мястото, където тази комбинация от байтове е нещо друго. Така че "Замяна на всички" най-вероятно не се повозим.

Още същата грешка: кодиране. В резултат на масата на българските букви са рекодират два пъти, като става нечетлив бъркотия. Има само обърнете внимание на вътрешно кодиране на сървъра в настройките му, както и факта, че е писано в искането да бъдат възстановени на маса. Например, имах случай, когато самата маса имаше CP1251 кодиране, и вътрешността на областта поотделно - latin1. Възстановени неразбираема каша. Имах една маса всички да се повтаря първите, които да поискат създаването му просто poubirav Latin1 колони. Всичко се оказа.

Тук, може би, и всичко останало. Успех, и не забравяйте да направите резервни копия на навременни.

Ако самостоятелно ремонт на базата данни няма начин - може да помогне

Контрол на копията на текста: обслужване TextMarket