Створення резервних копій баз MySQL

1. вступ
2. Як зробити копію бази MySQL
3. Автоматизація резервного копіювання
4. Додаткові можливості
5. посилання:

вступ

Ви працюєте над веб-проектом, в якому використовується СУБД MySQL. Звичайно, кожен серйозний проект передбачає, що періодично створюватиметься резервна копія всіх даних, які використовуються в роботі. Це де факто стандартний підхід. Більш того, без цього неможливо гарантувати відвідувачам сайту безперебійність роботи Вашого ресурсу. У разі, якщо сайт надає комерційні послуги, наявність резервного копіювання є просто-таки життєвою необхідністю.

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

Зробити копію всіх статичних HTML- і інших документів просто. Так само нескладно періодично "відкладати в сторону" і копії скриптів. Набагато складнішою видається завдання створення копії (далі backup) такої динамічної структури, як база даних MySQL. Основні труднощі, які виникають перед адміністратором розміщеного на хостингу сайту, зазвичай бувають такі:

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

2. Відсутність у адміністратора знань про те, як взагалі треба робити backup. Зазвичай таке завдання виникає тільки, коли "клюнув смажений півень". Тобто, в разі аварії, вторгнення хакерів або в інших позаштатних ситуаціях. Веб-майстри просто не готові до негайного backup і починають судорожно вивчати документацію по MySQL, а час йде ...

3. У разі, якщо веб-майстер не володіє в достатній мірі навичками роботи зі спеціалізованими утилітами з пакету MySQL, можуть виникати труднощі, пов'язані з обмеженнями, що накладаються хостинг-провайдером на призначені для користувача аккаунти. Наприклад, якщо база дуже велика і її розмір перевищує ліміт на доступну користувачеві пам'ять (RAM), backup зробити буде складно. Потрібно користуватися тонкими настройками утиліт резервного копіювання, що іноді теж викликає труднощі на практиці.

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

Як зробити копію бази MySQL

існує програма mysqldump , Що дозволяє швидко і просто проводити операції по створенню резервних копій баз MySQL. Також mysqldump дає можливість робити дуже тонкі настройки для управління процесом створення резервних копій баз даних або окремих таблиць. Можна сказати, що mysqldump - це основний інструмент, яким Вам доведеться користуватися в тому випадку, якщо Ви будете робити backup MySQL.

Відразу візьмемо просте завдання, яку будемо вирішувати за допомогою mysqldump, і розберемося, що до чого. Є хостинг, є база даних DBNAME, яку виділив Вам хостинг-провайдер. Є хост HOST, на якому розміщений сервер MySQL, логін LOGIN до нього, порт PORT, на якому працює сервер, а також пароль PASS. Маючи всі ці дані, можна зробити dump (дамп, копію) бази DBNAME так (виконуємо в unix shell):

Після виконання даної команди у файлі dump.txt у нас буде копія MySQL-бази DBNAME. Це станеться тільки в тому випадку, звичайно, якщо всі параметри Ви задасте вірно, відповідно до настройками свого хостингу. Відразу потрібно сказати, що програма mysqldump проводить виведення результатів прямо Вам на STDIN, тобто, на екран. Потрібно перенаправляти вивід в який-небудь файл. Наприклад, як в даному випадку - "> dump.txt". Якщо цього не зробити, а база велика, Ви отримаєте на екран все ті мегабайти інформації, які в ній містяться.

Трохи розповімо про те, що ж робить mysqldump. Ця програма створює сценарій відновлення Ваших даних. Тобто, висновок mysqldump - це не якісь абстрактні і нечитані двійкові дані, а осмислений текст сценарію. Наприклад, якщо у Вашій базі була таблиця test, в якій було поле test2 з типом даних integer і одна-єдина запис "1111", то mysqldump створить приблизно такий сценарій:

Таким чином, mysqldump "опише" всі Ваші таблиці і створить INSERT-команди для відновлення даних в таблицях. Отже, ми перенаправляємо висновок mysqldump в текстовий файл, який потім використовуватимемо для відновлення. Розглянемо і цей процес - відтворення бази з резервної копії.

Для відновлення користуватимемося стандартною програмою mysql, яка входить в комплект поставки MySQL поряд з mysqldump. Припустимо, у нас є backup в файлі dump.txt. Нам потрібно відновити його в робочу базу. Наприклад, ми випадково видалили нашу базу даних, а тепер намагаємося виправити цю невдачу. Робимо так:

Тобто, змушуємо mysql-клієнт з'єднатися з сервером і виконати сценарій, який у нас є. Після виконання цієї команди у Вашій базі з'являться таблиці і дані з резервної копії. Зважайте на те, що дані будуть просто відновлюватися за сценарієм з dump.txt. Тобто, якщо таблиці, які згадуються в дампі бази, вже існують і мають іншу структуру, тут явно виникне помилка. Просто подивіться на сценарій і на робочу базу і уявіть, що Ви вручну виконуєте команди з сценарію. Якщо впевнені, що все буде добре - сміливо відновлюйте.

Розглянемо більш тонкі налаштування mysqldump:

Крім перерахованих ключів mysqldump має і ще кілька дуже корисних можливостей, які Ви можете застосовувати за обставинами. Повна документація по mysqldump доступна на сторінці http://dev.mysql.com/doc/refman/4.1/en/mysqldump.html .

Ще один дуже корисну пораду щодо використання mysqldump в хостингової середовищі. Як правило, при використанні хостингу на користувача накладаються деякі обмеження. Наприклад, не можна зайняти більше деякої кількості фізичної пам'яті (RAM, ОЗУ). mysqldump за умовчанням поміщає всі отримані від MySQL-сервера дані в пам'ять, а потім записує все це на диск. Відповідно, якщо провайдер дає Вам зайняти, наприклад, 30Мб пам'яті, а база, копію якої Ви робите за допомогою mysqldump, займає 50мб, звичайно, тут виникне помилка - mysqldump не зможе відпрацювати коректно і завершиться аварійно, про що Вам повідомить. Щоб "змусити" mysqldump писати дані відразу на диск, а не зберігати їх, нехай навіть і тимчасово, в пам'яті, використовуйте ключ --quick. Це вирішить проблему.

У разі, якщо база даних має великий обсяг, то дамп можна відразу заархівувати, а при відновленні бази передати команді mysql дані з архіву, наприклад, таким чином:

Автоматизація резервного копіювання

Тепер подумаємо, як би нам автоматизувати процес створення резервних копій бази даних. Отже, існує програма - cron. Вона дозволяє запускати процеси у вказаний користувачем час або з певною періодичністю. Відразу обмовимося - cron в загальному випадку існує тільки під Unix, так що, якщо Ви використовуєте для хостингу ОС Windows, проконсультуйтеся зі своїм хостинг-провайдером про те, як краще запускати процеси в потрібний час. Та й взагалі, мабуть, цей пункт буде цікавий тільки unix-користувачам.

В unix shell запускаємо crontab -e і створюємо таке правило запуску процесу створення копій бази:

Ця команда, запускаючись з cron опівночі (00:00) кожної доби, робить дамп Вашої бази DBNAME і архівує його архіватором gzip в файл-архів з ім'ям, відповідним поточній даті. Наприклад, якщо ми робимо dump 3 січня 2002 року, ім'я файлу з архівом буде 2002-01-03.gz. Для того, щоб отримати файли, по іменах яких можна зручно дізнатися дату їх створення, ми використовуємо команду date, яка є стандартною для всіх unix-систем. Ця команда дозволяє задавати довільний формат виведення дати, що ми і використовували - date "+% Y-% m-% d". Ми помістили цю команду в зворотні одинарні лапки (backticks), що в unix shell примушує вставити в команду (перебільшуючи) результат виконання іншої команди.

Зберігаємо правило для cron і чекаємо результатів. До речі, докладніше про cron можна почитати на сторінці "Планувальник завдань (cron)" . Отже, кожен день ми будемо мати на диску заархівовані копію нашої бази даних. Можна швидко знайти потрібний архів по його назві і відновити те, що зіпсувалося, наприклад. До речі, якщо Ви хочете автоматизувати видалення старих архівів, спробуйте скористатися cron і командою find, яка зазвичай є в unix. Запускаючи періодично find ~ / каталог-с-архівами -name "* .gz" -mtime +7, Ви будете видаляти архіви, які "старше" семи днів. Прочитайте документацію по find - вона доступна по команді man find в unix shell.

Якщо у Вас є машина, постійно підключена до інтернет, можна так само по cron копіювати створений Вами backup на неї. Звичайно, провайдерська хостинг-машина - це дуже надійна штука. Однак, як то кажуть, "береженого Бог береже". Стара як світ істина в певних умовах може і Вам допомогти. Використовуйте для копіювання на іншу машину команди ftp і scp. Додайте їх запуск в cron. Якщо Ваша машина підтримує з'єднання по протоколу ssh, використовуйте secure copy клієнт для копіювання файлів - scp. Читайте документацію по цій команді в man-сторінці man scp. Приблизний запуск: scp 2002-01-03.gz [email protected]: - закачуємо файл 2002-01-03.gz на машину your.host.ru авторизувавшись там під логіном login.

Додаткові можливості

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

посилання: