Резервное копирование базы данных MySQL: проблемы производительности

Люди,

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

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

Сделать резервное копирование mysqldump без блокировки - назначить низкий приоритет процессу или что-то в этом роде, OR
Найдите другой механизм резервного копирования, который будет лучше/быстрее/не блокируется.

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

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

Спасибо!

UPDATE: больше информации о моей среде: Ubuntu, последний LAMPP, Amazon EC2.

Ответ 1

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

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

Ответ 2

Изменить: (предыдущий ответ был предложением раба db для резервного копирования, затем я заметил, что Алекс решил это в своем вопросе.)

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

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

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

Ответ 3

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

С уважением,

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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