Какой самый быстрый способ импортировать большую резервную копию базы данных MySQL?

Question

Какой самый быстрый способ экспорта / импорта базы данных mysql с использованием таблиц innodb?

У меня есть производственная база данных, которую мне периодически нужно загружать на мою машину разработки для устранения проблем клиентов. В настоящее время мы делаем это, загружая наши обычные резервные копии базы данных, которые генерируются с помощью «mysql -B dbname», а затем gzipped. Затем мы импортируем их, используя «gunzip -c backup.gz | mysql -u root».

Из того, что я могу сказать из чтения "mysqldump --help", mysqldump запускает wtih --opt по умолчанию, который выглядит так, как будто он включает в себя кучу вещей, которые, как я думаю, могут сделать импорт быстрее, такие как отключение индексов и импорт таблиц в виде одного массивного оператора импорта.

Есть ли лучшие способы сделать это или дальнейшая оптимизация, которую мы должны делать?

Примечание: В основном я хочу оптимизировать время, необходимое для загрузки базы данных на мою машину для разработки (сравнительно недавно MacBook Pro с большим количеством оперативной памяти). Время резервного копирования и передачи по сети в настоящее время не является большой проблемой.

Обновление:

Чтобы ответить на некоторые вопросы, поставленные в ответах:

• Схема производственной базы данных изменяется до пары раз в неделю. Мы запускаем рельсы, поэтому относительно легко запустить сценарии переноса для устаревших производственных данных.

• Нам необходимо помещать производственные данные в среду разработки потенциально ежедневно или ежечасно. Это полностью зависит от того, над чем работает разработчик. У нас часто возникают специфические проблемы с клиентами, которые являются результатом того, что некоторые данные распределены по нескольким таблицам в БД, которые необходимо отлаживать в среде разработки.

• Честно говоря, я не знаю, сколько времени займет mysqldump. Менее 2 часов, так как в настоящее время мы запускаем его каждые 2 часа. Однако это не то, что мы пытаемся оптимизировать, мы хотим оптимизировать импорт на рабочую станцию ​​разработчика.

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

Answer 1

Зависит от того, как вы определяете «самый быстрый».

Как говорит Джоэл, время разработчика стоит дорого. Mysqldump работает и обрабатывает множество случаев, которые в противном случае вам пришлось бы обрабатывать самостоятельно или тратить время на оценку других продуктов, чтобы увидеть, справляются ли они с ними.

Соответствующие вопросы:

Как часто меняется схема вашей производственной базы данных?

Примечание: Я имею в виду добавление, удаление или переименование таблиц, столбцов, представлений и т. П., Т. Е. Вещей, которые нарушают действительный код.

Как часто вам нужно помещать производственные данные в среду разработки?

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

Сколько времени занимает mysqldump?

Если это менее 8 часов, это можно сделать в одночасье как хрон. Проблема решена.

Вам нужны все данные?

Другой способ оптимизировать это - просто получить соответствующее подмножество данных. Конечно, для этого требуется написать собственный скрипт для получения подмножества сущностей и всех соответствующих связанных сущностей, но он даст самый быстрый конечный результат. Сценарий также необходимо поддерживать с помощью изменений схемы, так что это трудоемкий подход, который следует использовать в качестве абсолютного последнего средства. Производственные образцы должны быть достаточно большими, чтобы включать достаточно широкую выборку данных и выявлять любые потенциальные проблемы с производительностью.

Заключение

В основном, просто используйте mysqldump, пока вы абсолютно не сможете. Время, потраченное на другое решение, - это не время, потраченное на разработку.

Answer 2

Рассмотрите возможность использования репликации. Это позволит вам обновлять свою копию в режиме реального времени, а репликация MySQL позволяет наверстать упущенное, даже если вам нужно выключить подчиненное устройство. Вы также можете использовать экземпляр Parallell MySQL на вашем обычном сервере, который реплицирует данные в таблицу MyISAM, которая поддерживает резервное копирование в онлайн-хранилище. MySQL допускает это до тех пор, пока таблицы имеют одинаковое определение.

Другой вариант, на который стоит обратить внимание, - XtraBackup от известных специалистов по производительности MySQL Percona. Это онлайн-решение для резервного копирования InnoDB. Однако сам на это не смотрел, поэтому я не буду ручаться за его стабильность или за то, что это даже реальное решение вашей проблемы.