У мене в блозі WordPress працює база даних MySQL, яку я хочу регулярно створювати резервні копії. Було б краще використовувати програму mysqldump або сценарій mysqlhotcopy для створення резервних копій? Які плюси і мінуси кожного? Чи є інші варіанти, які я повинен розглянути?
Відповіді:
Я можу вам сказати, що в даний час я використовую mysqldump для підтримки резервної копії моєї бази даних. Я роблю це, тому що моя мета - тримати щотижневі резервні копії, щоб у випадку, якщо хтось видалить свої веб-сторінки, я можу відновити його не більше тижня тому.
Хороша річ у тому, що це базовий текстовий файл, тому я можу імпортувати його на будь-який комп’ютер з MySQL, завантажити його та шукати відсутні дані. Примітка: щоб отримати те, що я хотів, команда, яку я використовую в своєму сценарії, полягає в наступному:
mysqldump --databases databaseName > /file/pathСаме --databasesце змушує mysqldump скидати CREATE DATABASE IF NOT EXISTзаголовки, щоб я міг імпортувати його куди завгодно.
Хоча цей метод працює для мене, я впевнений, що там є кращі методи для інших цілей. Я також можу сказати, що як і для будь-якого рішення для резервного копіювання, ви можете зберігати його принаймні на іншому комп’ютері, і бажано в іншому місці (нашому в хмарі), якщо можете.
Я б розглядав можливість використання плагіна WordPress під назвою "Резервне копіювання бази даних WordPress (WP-DB-резервне копіювання)", який також вказаний у посібнику із резервного копіювання бази даних Wordpress . Цей плагін може створити резервну копію бази даних за розкладом та надіслати її електронною поштою (якщо вважати її невеликою базою даних). Ви також можете просто створити резервну копію локально. Ви можете виключити спам-коментар та зміни, щоб зменшити БД
Менший контроль, але простіший у здійсненні.
Дамп MySQL дає вам найбільше контролю . Ваша послуга хостингу також може бути обмежуючим фактором. Деякі хости не дають вам доступу до виконання завдань cron або виконання команди mysqldump.
Якщо ви робите резервні копії екземпляра MySQL, найкраще налаштувати MySQL Replicaton так, щоб будь-яке накладення завантаження сервера або збільшення вводу / виводу диска ніяким чином не впливало на вашу виробничу базу даних.
Після налаштування MySQL Replication ви можете скриптувати mysqldump різними способами ( будь ласка, дивіться мій пост у DBA StackExchange для різноманітних методів ), поки ви запускаєте ці mysqldumps на Slave.
Якщо ви не можете налаштувати інший сервер для реплікації MySQL, і всі ваші дані є InnoDB, вам доведеться виконати поточний mysqldump. Це робиться за допомогою --single-transactionопції з mysqldump. Таким чином, якщо ви запустили mysqldump, починаючи опівночі, а резервне копіювання закінчилося о 12:15, вихід mysqldump при відновленні відображатиме дані станом на 12:00 ранку.
Ще одна програма, доступна для MySQL Backups - це XtraBackup від Percona.
XtraBackup - це всеосяжний інструмент, який веде себе як rsync, але має спрямовану мету в житті. Він може почати копіювати всі дані InnoDB і таблиці. Він має можливість створювати контрольно-пропускні пункти внутрішньо та виконувати на місці відновлення аварії InnoDB, щоб допомогти отримати ідеальне резервне копіювання часу. XtraBackup також має додаткову функцію, яка дозволяє створювати додаткові резервні копії. Ще однією додатковою особливістю є створення файлів журналів InnoDB, також побудованих за допомогою відновлення після аварії на місці. Існує також програмне забезпечення для обгортки для забезпечення замороженого копіювання таблиць MyISAM.
Він виконує задню частину MySQL Instance, але з чіткою різницею. Момент часу резервного копіювання базується на тому, коли резервне копіювання завершено, а не тоді, коли воно почалося. Таким чином, якщо ви запустили XtraBackup, починаючи опівночі, а резервне копіювання закінчилося о 12:15, результат виводу mysqldump при відновленні відображатиме дані станом на 12:15 ранку.
Залежить від вашої системи зберігання ваших столів. Він працює лише для таблиць ARCHIVE та MyISAM, що відповідають цій сторінці посібника MySQL і повинен працювати на одній машині (тобто не використовуючи локальний сокет або TCP / IP)
Якщо ви робите резервну копію на сервері, і всі ваші таблиці - це таблиці MyISAM, подумайте про те, використовуючи функцію mysqlhotcopy, оскільки вона може робити швидше резервне копіювання та швидше відновлювати.
Рекомендую використовувати один із безлічі попередніх сценаріїв резервного копіювання mySQL, щоб усунути біль, щоб виправити це.
Я використовую "automysqlbackup", що є скриптом оболонки з відкритим кодом, який можна встановити як роботу із запитом на сервер. Він охоплює майже кожну можливу ситуацію резервного копіювання: http://sourceforge.net/projects/automysqlbackup/ . Він працював бездоганно для мене кілька років - ретельно рекомендував.
mysqlhotcopy - це сценарій Perl близько 2005 року. Таким чином, це додає залежності для Perl та різних Perl. Я б передав цей.
mysqldump - це програма C, яка поширюється за допомогою MySQL та активно підтримується. Якщо ви додасте опцію -x, вона заблокує таблиці, щоб ви були золотими.
У мене особисто цей скрипт є в cron (ви хочете видалити ці `Escape, якщо ви хочете запустити його вручну), і він працює як шарм для мене, створюючи резервну копію кожної з моїх баз даних у локальному файлі, а також повний дамп всіх баз даних.
І якщо у вас є більше однієї бази даних, ви також захочете скинути гранти на них. Maatkit допоможе вам там, і ви просто будете mk-show-grants -uroot -pPASSWORD > mygrantsdatabase.sqlмати резервні копії таблиць грантів та готові знову імпортувати.
Я також знаю, що ряд інструментів управління сервером, таких як Interworx та Ensim, використовують mysqldump для резервного копіювання баз даних, а потім просту команду mysql для відновлення. Звідси можна було б здогадатися, що це один із найкращих способів.