Mysql - як відновити базу з
База даних MySQL, що складається з таблиць InnoDB - штука хороша. Але вона може стати джерелом серйозних проблем, якщо одного разу у вас "впаде" сервер, і не виявиться під рукою свіжих бекапів. У випадку з таблицями MyISAM - досить просто скопіювати файли з каталогу загиблої бази даних в нову порожню БД. З InnoDB такий фокус, на жаль, не пройде. Але відновлення, проте, майже завжди можливо. Отже, приступимо.
Мінімум, який вам буде потрібно для відновлення - файли .ibd і * .frm від навернулися бази даних MySQL. Повинно бути 2 файли від кожної таблиці. Якщо ви їх не знайшли в старій базі даних - все зовсім сумно. Швидше за все це означає, що дані всіх таблиць зберігалися в одному файлі, а це зовсім інша історія. В цьому випадку залишається поспівчувати, і порадити в майбутньому в налаштуваннях MySQL не забувати встановлювати вельми корисний параметр:
[Mysql]
innodb_file_per_table = 1
Ну а якщо * .ibd і * .frm знайшлися - відновлення хоч і буде кілька утомливих процесом, але швидше за все завершиться успішно. У першому досвіді мені дуже допомогла ось ця (1) і ця (2) статті, однак, довелося йти своїм шляхом.
Для початку, збираємо новий MySQL сервер, бажано тієї ж версії, що був на постраждалій БД. Дізнатися версію можна, наприклад, з файлу лога БД. Версія ОС, в цілому, не важлива. Але під Unix є більше всяких примочок. У будь-якому випадку, настійно рекомендую не користуватися робочим MySQL сервером, бо в результаті наступних шаманських дій він може накритися, і проблем у вас тільки лише додасться. Під Windows речі все благополучно минуло й з пакетом Денвер, а всі команди можна виконувати з його phpMyAdmin. А ось при відновленні InnoDB Percona Server, не залишилося нічого іншого, як споруджувати сервер під Юнікс.
Поїхали. Не забувши про innodb_file_per_table = 1 в настройках, створюємо базу даних з тим же ім'ям, що і потерпіла. Створюємо в ній таблицю, вказавши для неї ім'я відновлюваної:
CREATE TABLE `sometable` (` id` INT PRIMARY KEY) ENGINE = Innodb;
Тепер зупиняємо MySQL, підміняємо в ньому .frm файл нашим старим від цієї таблиці, а .ibd скопіюємо собі "для дослідів". Запускаємо MySQL, і виконуємо SHOW TABLE `sometable`;
Ура! Тепер у нас є структура загиблої таблиці! А в першій з посилань стверджувалося, що без неї нічого не відновити. Тепер можна (не забуваючи при таких копіювання зупиняти MySQL) спробувати підмінити файл .ibd нашим, з даними. Пробуємо виконати select, і. сервер з гуркотом падає. Щоб зрозуміти в чому справа, заглянемо в його лог: "Id таблиці sometable такий-то, проте повинен бути таким-то!". Ось це і є головна печаль. База даних запам'ятовує у себе id кожної таблиці, і перевіряє його (він зберігається в .ibd файлах).
Тепер у вас є 2 шляхи, щоб подружити id старої таблиці, і id в новій базі даних. Один з варіантів - підмінити id в самій базі даних. Ну, якщо у вас вийде - це добре. Помось в цьому може утиліта, яка працює співаю Юнекс ось звідси. У мене вона успішно відкомпільоване, але при спробі виконати ./ibdconnect -o / usr / local / mysql / ibdata1 -f / usr / local / mysql / someDB / sometable.ibd -d someDB -t sometable на жаль, фокус не пройшов. Вона правильно вказала id, але написала про помилку при спробі його зміни. Ну що ж, можна просто перед створенням нової таблиці накрутити лічильник нової бази даних, щоб він збігся зі створюваною таблицею. Для цього просто скриптом створюємо-видаляємо таблиці, як це зробити - є в першій посиланням. Якщо у вас багато таблиць - краще обери таблицю з мінімальним Id. Щоб скинути лічильник сервера MySQL - потрібно перебудувати базу даних, і може бути доведеться видалити 3 файлу ib *.
skip-innodb_checksums = 1
innodb_force_recovery = 5
Якщо таблиця відкриється - терміново її зберігайте. ) А ось якщо таблиця була великою - все знову впаде з колишньою помилкою. Справ в тому, що цей id всередині файлу може повторюватися багато разів, на початку кожної внутрішньої сторінки. Так що доведеться акуратно пройтися пошуком по всьому файлу, помінявши id там де він дійсно id і не чіпаючи там, де ця комбінація байт є чимось іншим. Так що "замінити все" швидше за все не прокотить.
Ще одні граблі: кодування. У вийшла таблиці українські літери могли двічі перекодувати, перетворившись в нечитаемую кашу. Там що відразу звертайте увагу на внутрішню систему кодування сервера в його налаштуваннях, і на те, що написано в запиті відновлюваної таблиці. Наприклад, у мене був випадок, коли сама таблиця мала кодування CP1251, а внутрішні поля окремо - latin1. Відновилася незрозуміла каша. Довелося для таблиці все повторити спочатку, в запиті її створення просто поприбирати latin1 для стовпців. Все вийшло.
Ось, мабуть, і все. Удачі, і не забувайте робити своєчасні бекапи.
Якщо ж самостійно відновити базу даних немає можливості - можемо допомогти
Контроль за копіями цього тексту: сервіс TextMarket