Какой самый быстрый способ создать дамп и загрузить базу данных MySQL InnoDB с помощью mysqldump?

StackOverflow https://stackoverflow.com/questions/131085

  •  02-07-2019
  •  | 
  •  

Вопрос

Я хотел бы создать копию базы данных примерно с 40 таблицами InnoDB и объемом данных около 1,5 ГБ с помощью mysqldump и MySQL 5.1.

Каковы наилучшие параметры (т. е.:--single-transaction), что приведет к максимально быстрому дампу и загрузке данных?

Кроме того, при загрузке данных во вторую базу данных быстрее ли:

1) передайте результаты непосредственно во второй экземпляр сервера MySQL и используйте опцию --compress

или

2) загрузите его из текстового файла (т.е.:mysql < my_sql_dump.sql)

Это было полезно?

Решение

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

Другие советы

БЫСТРЫЙ сброс остановленной базы данных:

Использование опции "-T " с mysqldump приводит к появлению большого количества файлов .sql и .txt в указанном каталоге.Это на ~ 50% быстрее для выгрузки больших таблиц, чем один SQL-файл с инструкциями INSERT (занимает на 1/3 меньше времени работы настенных часов).

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

Доведя описанные выше стратегии до их логической крайности, можно было бы создать скрипт для широкого параллельного сброса базы данных.Ну, это именно то, что делает Maakit mk-parallel-dump (см. http://www.maatkit.org/doc/mk-parallel-dump.html) и инструменты mk-parallel-restore являются;скрипты perl, которые выполняют несколько вызовов базовой программы mysqldump.Однако, когда я попытался использовать их, у меня возникли проблемы с завершением восстановления без ошибок дублирования ключей, которые не возникали при использовании ванильных дампов, поэтому имейте в виду, что ваш пробег может отличаться.

Сброс данных из ДЕЙСТВУЮЩЕЙ базы данных (без прерывания обслуживания):

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

К сожалению, -T несовместим с --single-транзакцией, поэтому вы получаете только одну.

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

Передача дампа по Сети обычно является выигрышной

Чтобы прослушать входящий дамп на одном хосте, запустите:

nc -l 7878 > mysql-dump.sql

Затем на вашем хосте базы данных запустите

mysqldump $OPTS | nc myhost.mydomain.com 7878

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

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

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

Несмотря на то, как часто вы видите эти флаги в примерах mysqldump и руководствах, они излишни, поскольку включены по умолчанию:

  • --opt
  • --add-drop-table
  • --add-locks
  • --create-options
  • --disable-keys
  • --extended-insert
  • --lock-tables
  • --quick
  • --set-charset.

От http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html:

Использование --opt аналогично указанию --add-drop-table, --add-locks, --create-options, --disable-keys, --extended-insert, --lock-tables, --quick и --set-charset.Все опции, обозначающие --opt, также включены по умолчанию, потому что по умолчанию включен параметр --opt.

Из этих вариантов поведения "--quick" является одним из наиболее важных (пропускает кэширование всего результирующего набора в mysqld перед передачей первой строки) и может использоваться с "mysql" (который ПО умолчанию НЕ включает --quick), чтобы значительно ускорить запросы, возвращающие большой результирующий набор (например, сброс всех строк большой таблицы).

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

Для innodb, --order-by-primary --extended-insert обычно является лучшей комбинацией.Если у вас после каждого последнего бита производительности и в целевом поле много ядер процессора, вы можете захотеть разделить результирующий файл дампа и выполнять параллельные вставки во многих потоках, вплоть до innodb_thread_concurrency / 2.

Кроме того, настройте innodb_buffer_pool_size для целевого объекта на максимум, который вы можете себе позволить, и увеличьте innodb_log_file_size до 128 или 256 МБ (будьте осторожны с этим, вам нужно удалить старые файлы журналов перед перезапуском демона mysql, иначе он не перезапустится)

Используйте инструмент mk-parallel-dump из Maatkit.

По крайней мере, это, вероятно, было бы быстрее.Я бы больше доверял mysqldump.

Как часто вы это делаете?Действительно ли это проблема с производительностью приложения?Возможно, вам следует разработать способ сделать это, при котором не нужно сбрасывать все данные целиком (репликация?).

С другой стороны, 1.5G - это довольно маленькая база данных, так что, вероятно, это не будет большой проблемой.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top