Можливо, ви введете код, який зрештою знищить кеш, який надає дані мільйонам людей,
Можливо, ви оновите програму і в кінцевому підсумку видалите інформацію, для якої немає резервної копії,
Або, можливо, ви внесете зміну, яка «працює на вашій машині», але повністю закриває репозиторій керування джерелами.

І є маса інших прикладів. Я впевнений, що ти сам швидко назвеш ще п’ять.

Я взяв (начебто каламбур) свою долю всього вищезазначеного, але одну з речей, які я бачу від людей, які працюють у нашому просторі.

Тобто ті, хто працює з веб-додатками, що базуються на базі даних, – це відсутність розуміння організації бази даних на рівні файлової системи та того, як можна реконструювати дані, навіть якщо у вас немає стандартної резервної копії, з якою можна працювати.

У цій публікації я збираюся глибоко зануритися в організацію бази даних MySQL на рівні файлової системи, як ви можете відновити інформацію з неї порівняно з файлом резервної копії, якщо ви опинитесь у такій ситуації, і надати посилання (або закладки) вони тобі потрібні.

Реконструкція даних MySQL

Щоб було зрозуміло, я буду говорити про базу даних MySQL, яка працює на варіанті операційної системи на базі *nix (тобто ви дивитесь на дистрибутив Linux або macOS).

Розташування файлів (про які я коротко розповім) буде відрізнятися в системі на базі Windows, але вам доведеться звернутися до посібника MySQL або подібного ресурсу, щоб знайти їх.

Головне: перш ніж заглиблюватися в цю статтю, дізнайтеся, де у вашій операційній системі знаходяться файли. Наприклад, якщо ви використовуєте macOS, і ви, ймовірно, знайдете його в /usr/local/mysql/data.

Я вважаю за краще використовувати Homebrew, тому мої бази даних MySQL знаходяться в /usr/local/var/mysql . І, як ви бачите вище, ви помітите файли, які мають ті самі назви, що й бази даних у вашій системі .

Як організовані бази даних

На поверхневому рівні це виглядає досить просто. Але якщо ви відкриєте каталог, як згадувалося вище, ви побачите, що більшість із того, що ви бачите, є каталогами, а не файлами, як такими, які містять більше інформації.

Якщо ви заглибитеся в один із каталогів, ви побачите різноманітні файли:

До них належать файли таких типів:

СВІТ
MYI
FRM
IBD

І кожен із цих типів файлів існує для кожної таблиці в базі даних.

Тож давайте розглянемо їх більш детально, щоб краще зрозуміти, з чого саме складається база даних.

1 База даних — це набір файлів

Загалом, більшість із нас знають, що MySQL — це реляційна база даних, і кожна база даних складається з набору таблиць, усі з яких зберігають різні типи інформації (і багато таблиць певним чином пов’язані одна з одною, навіть якщо це лише значення в один стовпець).

Але ця публікація не про реляційний аспект бази даних і не про те, як ми можемо виконувати запити до неї. (Якщо вам цікаво, спробуйте – усе це засновано на кортежному численні .)

Натомість мова йде про розуміння того, що для кожної таблиці існує набір файлів, які посилаються на інформацію, що міститься в кожній таблиці. І

2 Розуміння типів файлів

Оскільки кожна таблиця в базі даних складається з наведених вище типів файлів, давайте розглянемо окремий тип файлу, а потім визначимо роль, яку він відіграє для кожної таблиці (і, зрештою, як це впливає на всю базу даних).

MYD. Цей файл містить дані, які зберігаються в рядках таблиці бази даних. Цей файл тісно пов’язаний з файлом FRM.
FRM. Цей файл містить дані формату таблиці (що включає такі речі, як структура кожного стовпця бази даних, тип даних, які він містить тощо).
MYI. Це індекс бази даних. Якщо ви використовуєте базу даних MyISAM (яку зараз більшість із нас використовує InnoDB), у вас буде цей файл. Крім того, дані містять інформацію про те, чи були дані належним чином закриті. Вважайте це файлом цілісності самої таблиці. Не інформація в ньому, не його формат.
IBD. Це тип файлу, який асоціюється з таблицями бази даних InnoDB (тому ви можете не побачити цього в каталозі вашої бази даних). Однак якщо ви це зробите, важливо знати, що бази даних на основі InnoDB зберігатимуть інформацію про кожну таблицю в цьому файлі.

У наведеній вище інформації є ще дві теми, які варто вивчити.

MyISAM
InnoDB

Перш ніж розглядати кожну з них, зауважте, що MyISAM і InnoDB — це те, що називають механізмами зберігання. Це звучить дивно, але це пов’язано з тим, як програмне забезпечення бази даних керує операціями створення, читання, оновлення та видалення інформації.

MyISAM & InnoDB: у чому різниця?

Кожен із цих механізмів зберігання відрізняється тим, як вони працюють з транзакціями, блокуванням, відкатами та пошуком. Для тих, хто є адміністраторами баз даних, ви знайомі з усім вищезазначеним (але ви також, ймовірно, не читаєте цього 🙃).

Звичайно, не цей тип двигуна.

Для решти з нас це те, що ми маємо:

Транзакції відбуваються щоразу, коли принаймні два оператори, як-от SELECT і UPDATE або INSERT і DELETE, або будь-яка їх комбінація (або більше) використовуються в поєднанні один з одним. Отже, якби ви ВИБРАЛИ інформацію, а потім ВИДАЛИЛИ результати, ви мали б транзакцію.
- MyISAM не підтримує транзакції. Це означає, що якщо «транзакція» переривається, це впливає на будь-які дані, які оброблялися під час операції. Потрібно сказати, що це не використовується.
- InnoDB, з іншого боку, гарантує, що зміни не будуть внесені до таблиці, доки транзакція не буде завершена. Іншими словами, зміни не будуть зафіксовані в базі даних.
Для кожного механізму зберігання блокування змінюється на рівні таблиці або рядка. Щоразу, коли ви виконуєте запит до таблиці, MyISAM блокуватиме всю таблицю, доки процес не буде завершено. InnoDB, з іншого боку, блокуватиме лише ті рядки, які зазнали впливу. Це важлива відмінність, оскільки це означає, що ви можете продовжувати працювати з таблицею, але не з тими самими рядками, щоразу, коли ви використовуєте InnoDB.
Відкат неможливий у MyISAM. Це означає, що як тільки зміна внесена, вона зроблена. InnoDB пропонує відкат. Отже, припустимо, ви вносите зміни в таблицю, ви випадково зробили щось, чого не збиралися робити, тоді ви можете відкотити її до попереднього стану. Однак це не слід плутати з резервним копіюванням. Це більше схоже на операцію «відмінити» транзакцію.
Пошук, особливо в тому, як ми структуруємо наші бази даних, є ключовим у тому, як ми організовуємо дані в наших базах даних. Простіше кажучи, InnoDB підтримує повнотекстове індексування (починаючи з MySQL 5.6.4). Але якщо ваш хост або провайдер не допускає індексів FULLTEXT, я б стверджував, що це не порушує угоду.

Враховуючи всю наведену вище інформацію, кожен бачить, що переваги механізму зберігання даних InnoDB значно переважають переваги механізму зберігання даних MyISAM, особливо якщо ви маєте намір використовувати версію MySQL, що принаймні дорівнює 5.6.4.

3 Повторне створення бази даних

На цьому етапі припустімо, що ви знаєте, що маєте доступ до файлів, які складають базу даних, з операційної системи.

Можливо, це попередня резервна копія, можливо, ви можете знайти файли на диску або, можливо, ви можете отримати їх іншим способом – і вам потрібно відновити базу даних до попередньої точки.

1 Не робіть цього на виробництві

Перш ніж щось робити, створіть порожню базу даних на локальній машині, а потім попрацюйте над імпортом інформації. Але, знову ж таки, це не те, що просто використовувати інтерфейс бази даних для імпорту файлу SQL.

Натомість створіть каталог, який відповідає імені бази даних, яку ви хочете створити. У цій публікації я використаю приклад trunkdev (оскільки тут я працюю з найновішою версією зі стовбура WordPress ).

2 Створіть резервну копію наявної бази даних

Далі зробіть резервну копію існуючої бази даних, наскільки це можливо, – будь то за допомогою інтерфейсу бази даних або копії файлів. Після цього скопіюйте файли з вихідного розташування в створений вами каталог.

На цьому етапі ви повинні мати можливість завантажити вибраний інтерфейс бази даних і переглянути інформацію, яка міститься у файлах бази даних, які ви щойно скопіювали. Це залежить від того, чи файли не пошкоджено, а сервер бази даних працює.

3 Не встановлюйте інше програмне забезпечення

Зауважте, що на даний момент я б не намагався встановити на нього інше програмне забезпечення, наприклад WordPress, або будь-яку іншу інформацію. Натомість працюйте безпосередньо з даними. Якщо припустити, що він видимий у вашому інтерфейсі, зробіть належну резервну копію або експортуйте файл у файл SQL, щоб легше було відновити інформацію в майбутньому.

Деякі інтерфейси нададуть вам можливість експортувати лише певні таблиці. У цьому випадку зробіть резервну копію всього. Для деяких баз даних це займе багато часу; для інших не дуже. Все залежить від розміру проекту.

4 Робота з даними

На цьому етапі ви зможете почати працювати з базою даних за допомогою інтерфейсу або SQL. Якщо вам не зручно або навіть не впевнені, як це зробити, тоді поговоріть з кимось, хто знає, оскільки це може бути надзвичайно чутливою справою (зрештою, ви маєте справу з відновленням бази даних із файлів, чи не так?)

Коли ви переконаєтеся, що у вас є інформація в місці, яке готове до відновлення будь-якої програми, яку втрачено, пошкоджено або просто має некоректні дані, тоді настав час підготуватися взяти інформацію з локальної машини та надіслати її назад до джерело.

Назад до джерела

По-перше, все вищезазначене рекомендується робити під час низького трафіку, тому переконайтеся, що коли ви це робите, ви не будете робити це в години пік. Це само собою зрозуміло.

Потім зробіть резервну копію бази даних, перш ніж почати з нею працювати. Збережіть файл у місці, яке можна легко відновити та легко отримати до нього, щоб, якщо щось піде не так із використанням інформації, яку ви збираєтеся імпортувати, ви будете забезпечені та просто відновите те, що вже було там. Для зрозумілості експортуйте всю базу даних у форматі SQL.

Тепер візьміть базу даних, яка є у вас на локальній машині, і також експортуйте цю інформацію у файл SQL. Відкрийте експортований файл і переконайтеся, що він використовує інструкцію CREATE для створення бази даних із належним ім’ям і таблиць із відповідними іменами.

Якщо все піде добре, усе, що ви імпортували, буде відновлено саме так, як має бути, і як ви бачите на своєму локальному пристрої. Якщо ви цього не бачите, імпортуйте файл, який ви експортували раніше; інакше все готово.

Що робити, якщо це не спрацює?

Якщо це не спрацює, вам доведеться приступити до основної проблеми:

Не спрацювало через щось не так із файлами на сервері?
Це не спрацювало через тип бази даних, яку ви створили на локальній машині?
Ви використовуєте ту саму систему зберігання? Ви повинні бути, оскільки це надходить із файлів.
Чи надійна локальна цілісність бази даних?
Чи видаляється база даних на сервері перед імпортом даних із локальної машини?

Якщо на даний момент він не працює, зазвичай причиною є те, що описано вище. Однак це може бути щось інше. Я зробив усе можливе, щоб надати якомога більше інформації про бази даних MySQL, їхню структуру та кроки, необхідні для реконструкції бази даних із файлів, але я не можу охопити кожен потенційний крайовий випадок.

Завжди створюйте резервні копії даних (і не припускайте, що це робиться)

Тим не менш, я сподіваюся, що вся наведена вище інформація дає глибше розуміння того, що лежить в основі WordPress, якщо ви зіткнетеся з цією проблемою самостійно або з клієнтом.

І, нарешті, завжди резервне копіювання. Робіть резервні копії вручну, створюйте автоматичні резервні копії та робіть їх часто. Також не обмежуйте його базою даних. Резервне копіювання бази даних, програми та всього іншого, що необхідно для роботи рішення.

Якщо ви це зробите, то вам не доведеться турбуватися про все вищезазначене.

Джерело запису: tommcfarlin.com