Възстановяване на отдалечен MySQL база данни

Под ръка хвана virtualke с CentOS 5.6 x86_64 и MySQL 5.0.77
тест база данни е създадена с няколко таблици като MyISAM и InnoDB. И няколко съхранени процедури за тестване на тяхното възстановяване:

Е, има малко данни за създаване на:

избрал много прост принцип да разгледа сценарий тест е възможността за възстановяване.

Fur промъкнал незабелязано

След като създадете и потвърдите, че базата данни отговаря и съдържа определена информация:

Копираш [чистачка с въже] база отстраняване с проста команда:

Според съветите от тази статия, ние не се рестартира сървъра и не спирай MySQL да останат отворени описания на файлове (в противен случай ще бъдат загубени информация, както и да се възстанови да се наложи директна намеса в файлова система).

Веднага може да се провери, че е описано в линка по-горе не работи Най-малкото защото контактът е изтрит:

Ако се опитате да prikonnektitsya чрез TCP, а след това ние все още ще бъдат разочаровани, защото MySQL не знае нищо за бази данни и mysqldump ще даде празен заключение:

Понякога също mysqldump да се закълна, че не може да се запише в mysql.time_zone_name маса:

mysqldump: не можа да се изпълни "/ * 40103 SET TIME_ZONE =! '+ 00:00" * / ": Таблица" mysql.time_zone_name "не съществува (1146)

но това е ключов параметър --skip-TZ-UTC

Така че ние се рови малко за това как MySQL съхранява в базите данни. база данни MySQL по отношение на дадена директория, в която се съхранява маси разделителна способност, индекси и данни (за случая само с маса определение InnoDB съхранява в директорията, както и данните се съхраняват в отделен файл). За да видите нашия MySQL база данни - това е достатъчно, за да види вътре в директорията / Var / ИЪ / MySQL /
ние трябва да възстанови всички файлове, които са били там - да се таблиците и данните в базата данни.
Процедури и функции не се съхраняват в основната база данни, и се намират в ргос на MySQL маса - така че тази база, също ще трябва да бъдат възстановени.
Дадена задача се улеснява от факта, че процесът на Mysqld е в ход, и държи отворени описания на файлове на изтрити файлове, и системата не изтриете файла, докато дръжката е затворен. / Proc файлова система осигурява достъп до тези файлове чрез връзките в / ргос / [PID] / РР / *

Ние го използвате, за да се намери и да се възстанови имената на базата данни, се филтрират само директории в / Var / ИЪ / MySQL / и да ги създаде в едно и също място:

база данни MySQL сега вижда:

Но mysqldump все още ще изнесе празнотата. Ние ще се опитаме да го поправим, възстановяване на останалите файлове, които са все още е отворен процес. За да направите това, да направи връзка от / Var / ИЪ / MySQL / до в / PROC файлове:

След тази операция mysqldump все още се връща невалидни, и ако попитате zaeksportit специфична маса - това ще се кълнат, че тази таблица не съществува:

Проблемът се състои в това, че файловете на масата дефиниция не винаги са отворени за процеса и достъпът до тях е рядкост, съответно, в предишните стъпки, за да "възстанови" не успяха файловете. Решението за наличието на определена маса за износ, осъществен на базата на таблици, които описват файл, така че автоматично износ провали.

Въпреки това, липсата на файл определение не е пречка за директен прием на данни от таблицата:

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

Способността да се възстанови база данни описание в статията се оказа неработеща (отпадна!).
Не се доверявайте на всички магически методи за възстановяване, които мигат в огромната мрежа. Направете резервни копия, създаване на план за възстановяване, и винаги проверявайте възможните сценарии за възстановяване, преди да се случи непоправима.