Резервное копирование базы данных MySQL: проблемы с производительностью - PullRequest
14 голосов
/ 13 июля 2011

Народ,

Я пытаюсь настроить регулярное резервное копирование довольно большой производственной базы данных (пол гигабайта), в которой есть таблицы как InnoDB, так и MyISAM.До сих пор я использовал mysqldump, но обнаружил, что это занимает все более длительные периоды времени, и сервер полностью не отвечает, пока работает mysqldump.

Я хотел бы спросить вашего совета: как мне либо

  1. Сделать неблокирующее резервное копирование mysqldump - назначить низкий приоритет процессу или что-то в этом роде, ИЛИ

  2. Найдите другой механизм резервного копирования, который будет лучше / быстрее / неблокирующим.

Я знаю о существовании продукта MySQL Enterprise Backup (http://www.mysql.com/products/enterprise/backup.html) - это дорого, и это не вариант для этого проекта.

Я читал оустановка второго сервера в качестве «ведомого по репликации», но это также не вариант для меня (для этого требуется оборудование, которое стоит $$).

Спасибо!

ОБНОВЛЕНИЕ: больше информациив моей среде: Ubuntu, последняя версия LAMPP, Amazon EC2.

Ответы [ 5 ]

8 голосов
/ 13 июля 2011

Если репликация на ведомое устройство невозможна, вы можете использовать файловую систему, в зависимости от используемой ОС,

Я использовал снимки ZFS для довольно большой базы данных MySQL (30 ГБ +) в качестве метода резервного копирования, и он выполняется очень быстро (не более нескольких минут) и не блокируется.Затем вы можете смонтировать снимок где-нибудь еще и сохранить его на ленте и т. Д.

5 голосов
/ 13 июля 2011

Редактировать: (в предыдущем ответе предлагалось создать резервную копию ведомого БД, затем я заметил, что Алекс исключил это в своем вопросе.)

Нет причин, по которым ваш ведомый по репликации не может работать на том же оборудовании, предполагая, что оборудование может не отставать.Возьмите архив с исходным кодом, ./configure --prefix=/dbslave; make; make install;, и у вас будет второй сервер mysql, полностью живущий в / dbslave.

EDIT2: Репликация также имеет ряд других преимуществ.Например, при запущенной репликации вы сможете восстановить журнал и воспроизвести его поверх последней резервной копии, чтобы восстановить дополнительные данные после определенных видов катастроф.

EDIT3 :Вы упоминаете, что работаете на EC2.Другая, несколько надуманная идея снизить расходы - попытаться настроить другой экземпляр с томом EBS.Затем используйте API-интерфейс AWS, чтобы раскрутить этот экземпляр достаточно долго, чтобы он мог догнать записи из двоичного журнала, выгрузить / сжать / отправить снимок, а затем развернуть его.Не бесплатное и трудоемкое в настройке, но значительно дешевле, чем запуск экземпляра 24x7.

2 голосов
/ 21 июля 2011

Попробуйте утилиту mk -rallel-dump из maatkit (http://www.maatkit.org/)

regards,

1 голос
/ 22 июля 2011

Что-то, что вы могли бы рассмотреть, - это использовать здесь двоичные журналы, хотя этот метод называется «доставка журналов».Непосредственно перед каждым резервным копированием, введите команду для очистки двоичных журналов, и затем вы сможете скопировать все, кроме текущего двоичного журнала, через обычные операции файловой системы.

Преимущество этого метода заключается в том, что вы вообще не блокируете базу данных, поскольку, когда он открывает следующий двоичный журнал в последовательности, он снимает все блокировки файлов в предыдущих журналах, поэтому обработка не должна быть затронутазатем.Tar'em, zip'em на месте, делайте, как вам угодно, затем скопируйте его как один файл в вашу резервную систему.

Еще одно преимущество использования двоичных журналов - вы можете восстановить до X времени.если логи доступны.Т.е. у вас есть полная резервная копия в прошлом году, и каждый журнал с тех пор и по настоящее время.Но вы хотите увидеть, какой была база данных 1 января 2011 года. Вы можете выполнить восстановление «до 2011-01-01», и когда оно прекратится, вы можете выполнить это до 1 января 2011 года, если это касается базы данных.

Мне пришлось использовать это один раз, чтобы обратить вспять ущерб, нанесенный хакером.

Определенно стоит проверить.

Обратите внимание ... двоичные журналы обычно используются для репликации,Ничто не говорит, что ты должен.

0 голосов
/ 22 июля 2011

В дополнение к тому, что Rich Adams и timdev уже предложили, напишите задание cron, которое запускается при малом периоде использования, чтобы выполнить задачу подчинения, как это предлагается, чтобы избежать высокой загрузки ЦП.

Проверьте mysql-parallel-dump также.

...