Недавно я обнаружил, что наши производственные веб-серверы, работающие на MySQL, не создаются регулярно (или вообще не создаются). Я привык к резервному копированию БД SQL Server, но не имею большого опыта работы с БД MySQL. Какие-либо лучшие практики для использования «mysqldump» или любых других инструментов резервного копирования БД?
Я, вероятно, выполню расписание по расписанию, чтобы оно выполнялось по ночам, а затем сделаю резервную копию файлов с помощью моей резервной системы.
Спасибо.
Ответы:
Лучшие практики для резервного копирования сервера MySQL:
Настройка репликации в MySQL. Вам нужно будет настроить главный и подчиненный сервер. Все операции чтения-записи в БД могут идти на ваш подчиненный сервер. Преимущество репликации состоит в том, что вы можете создавать резервную копию со своего подчиненного сервера, не прерывая работу главного сервера. Ваше приложение будет продолжать работать на главном сервере без каких-либо простоев.
Если ваш набор данных небольшой (я понимаю, что «маленький» - это относительный термин… для его определения, скажем, <10 ГБ), то mysqldump, вероятно, будет отлично работать. Это легко, это онлайн и очень гибко. Myqldump может сделать всего несколько вещей: сделать резервную копию всего или только определенных баз данных или таблиц, сделать резервную копию только DDL, оптимизировать дамп для более быстрого восстановления, сделать полученный файл sql более совместимым с другими RDBMS и многими другими.
Однако наиболее важные параметры связаны с целостностью вашей резервной копии. Мои любимые опции: --single -action: эта опция дает непротиворечивую резервную копию, если (и только если) таблицы используют механизм хранения InnoDB. Если у вас есть таблицы MyISAM, не предназначенные только для чтения, не используйте эту опцию при резервном копировании. --master-data = 2: эта опция обеспечит согласованность вашего дампа (выполняя блокировку всех таблиц, если вы не добавили опцию --single -action). Опция --master-data также записывает двоичную позицию журнала в результирующем файле дампа (= 2 заставляет эту строку быть комментарием в файле дампа)
Последнее замечание о mysqldump: имейте в виду, что время восстановления может быть значительно больше времени резервного копирования. Это будет зависеть от нескольких факторов, например, от того, сколько у вас индексов.
Для тех, у кого большие наборы данных, лучше всего использовать физическое резервное копирование. Хотя вы можете сделать холодное резервное копирование (т. Е. Закрыть службу MySQL, скопировать каталог данных, перезапустить службу), многие люди не хотят простоев. Мое любимое решение - снимки. Это может быть горячим (для InnoDB) или требовать краткой блокировки (для MyISAM). Не забудьте включить все ваши данные (включая ib_logfiles). Lenz предоставляет полезную утилиту, чтобы помочь с этим: http://www.lenzg.net/mylvmbackup/
Преимущества использования MySQL Enterprise Backup:
Ссылка: http://www.mysql.com/products/enterprise/backup/features.html http://www.mysql.com/products/enterprise/backup.html
Я бы порекомендовал настроить выделенную реплику для резервного копирования. Это позволит вам выполнять любые задачи резервного копирования, не влияя на основной. Поскольку это усложняет вашу архитектуру, вам нужно отслеживать задержку репликации, чтобы убедиться, что все работает.
Что касается самого процесса, у вас есть пара вариантов без каких-либо сторонних инструментов. Снимки могут быть приняты с помощью mysqldumpкоманды (предполагая , что вы используете InnoDB): mysqldump --all-databases --single-transaction > all_databases.sql. В зависимости от размера данных, может быть предпочтительнее закрыть MySQL и сделать резервную копию файлов данных напрямую. Когда реплика будет перезапущена, она воспроизведет все события, полученные первичным сервером за время, в течение которого она была недоступна. Если вы используете MySQL Enterprise, mysqlbackupутилита сделает это.
Инкрементное резервное копирование можно сделать, включив двоичный журнал на реплике. Очевидно, что это только запись событий, которые изменяют данные, поэтому вам нужно будет объединить это со снимками выше.
--single-transactionно не забудьте добавить,--events --routinesи я всегда использую--triggersтоже, хотя он включен по умолчанию, так как он может быть отключен в my.cnf. Я бы сказал, что в большинстве случаев полезно использовать их как стандартную практику, независимо от того, есть ли у вас в базе данных объекты такого типа или нет.