Есть ли более быстрый способ загрузки mysqldumps?

Возможный дубликат:
Ускорение дампов и импорта mysql

mysqldump достаточно быстро, но отвалы базы данных среднего размера (20-30 мегабайт) занимают несколько минут, используя mysql my_database < my_dump_file.sql

Есть ли какие-то настройки mysql, которые я могу настроить, чтобы ускорить загрузку? Есть ли лучший способ загрузить сохраненные данные?

Я экспериментировал с использованием утилиты mysqlimport с дампами на основе CSV. Эти нагрузки незначительно, но не заметно - быстрее. У меня возникает соблазн просто копировать необработанные файлы базы данных, но это похоже на плохую идею.

Ответы

Ответ 2

Предполагая, что вы используете InnoDB...

У меня была ситуация с кучей существующих выходных файлов mysqldump, которые я хотел импортировать в разумные сроки. Таблицы (по одному на файл) составляли около 500 МБ и содержали около 5 000 000 строк данных. Используя следующие параметры, мне удалось уменьшить время вставки с 32 минут до менее 3 минут.

innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 256M
innodb_flush_method = O_DIRECT

Вам также потребуется иметь достаточно большой параметр innodb_buffer_pool_size.

Поскольку мои вставки были одноразовыми, я снова возвращал настройки. Если вы собираетесь использовать их в долгосрочной перспективе, убедитесь, что вы знаете, что они делают.

Я нашел предложение использовать эти настройки в блоге Cedric Nilly, а подробное объяснение для каждого из параметров можно найти в Документация по MySQL.

Ответ 3

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

Если вы используете только таблицы MyISAM, вы можете безопасно скопировать их, остановив сервер, скопировав их на остановленный сервер и запустив это.

Если вы не хотите останавливать исходный сервер, вы можете выполнить следующее:

  • Получить блокировку чтения для всех таблиц
  • Очистить все таблицы
  • Скопировать файлы
  • Разблокировать таблицы

Но я уверен, что ваш экземпляр-сервер нужно остановить, когда вы положите их на место.

Ответ 4

Вы уверены, что данные правильные, и нет проблем с файловой системой или системой? Несколько минут для базы данных 20-30 мегабайт - это долгое время. Я нахожусь в MacBook с 2 ГБ оперативной памяти, 320 ГБ HD и стандартным процессором 2.1 ГГц. Я схватил одну из своих баз данных для быстрого теста:

gavinlaking$ du -sm 2009-07-12.glis
74  2009-07-12.glis
gavinlaking$ mysql -pxxx -e "drop database glis"
gavinlaking$ mysql -pxxx -e "create database glis"
gavinlaking$ time mysql -pxxx glis < 2009-07-12.glis 

real    0m17.009s
user    0m2.021s
sys 0m0.301s

17 секунд для файла размером 74 мегабайта. Это кажется мне довольно привлекательным. Даже если бы он был в 4 раза больше (он просто застенчивый 300 мегабайт), он заканчивается чуть менее 70 секунд.

Ответ 6

Существует метод использования снимков LVM для резервного копирования и восстановления, который может быть интересным для вас.

Вместо того, чтобы делать mysqldump, рассмотрите возможность использования LVM для создания моментальных снимков ваших каталогов данных MySQL. Использование моментальных снимков LVM позволяет иметь практически резервные возможности в реальном времени, поддержку всех механизмов хранения данных и невероятно быстрое восстановление. Чтобы процитировать ссылку ниже,

"Время восстановления так же быстро, как и восстановление данных и восстановление базы данных MySQL, и это может быть еще более сокращено".

http://www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-and-replication-setup/