У меня есть огромный дамп памяти объемом 32 ГБ, который мне нужно импортировать в MySQL. Раньше мне не приходилось импортировать такой огромный дамп SQL. Я сделал обычное:

mysql -uroot dbname < dbname.sql

Это занимает слишком много времени. Есть таблица с примерно 300 миллионами строк, которая за 3 часа достигла 1,5 миллиона. Таким образом, кажется, что все это займет 600 часов (это 24 дня) и нецелесообразно. Итак, мой вопрос, есть ли более быстрый способ сделать это?

Дополнительная информация / выводы

Все таблицы InnoDB, и внешние ключи не определены. Есть, однако, много индексов.
У меня нет доступа к исходному серверу и БД, поэтому я не могу создать новую резервную копию или сделать «горячую» копию и т. Д.
Настройка, innodb_flush_log_at_trx_commit = 2предложенная здесь, кажется, не дает (явно видимого / экспоненциального) улучшения.
Статистика сервера во время импорта (из MySQL Workbench): https://imgflip.com/gif/ed0c8 .
MySQL версия 5.6.20 сообщества.
innodb_buffer_pool_size = 16M и innodb_log_buffer_size = 8M. Нужно ли увеличить это?

mysql backup innodb mysqldump SBhojani
источник

Можете ли вы добавить более быстрые компоненты на сервер, а именно больше оперативной памяти и накопителя SSD?

@Bert сервер имеет 8 ГБ оперативной памяти, большая часть которой просто не используется. Также нельзя добавить больше памяти. Как это поможет? Действительно ли операции записи выполняются так медленно?

Что за узкое место? Процессорное ядро привязано?

Крис С

@ChrisS нет, загрузка процессора составляет от 3 до 4%. Я не уверен, что является узким местом. Я думаю, что это индексы. Как найти / подтвердить узкое место?

1

Если у вас есть sql, можете ли вы отредактировать операторы создания индекса и посмотреть, пойдет ли он быстрее? как только у вас есть импортированные данные, вам нужно будет воссоздать их

84

Вадим Ткаченко из Percona сделал это прекрасное наглядное представление InnoDB

InnoDB Архитектура

Вам обязательно нужно изменить следующее

innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 256M
innodb_log_file_size = 1G
innodb_write_io_threads = 16
innodb_flush_log_at_trx_commit = 0

Почему эти настройки?

innodb_buffer_pool_size будет кешировать часто читаемые данные
innodb_log_buffer_size : больший буфер уменьшает ввод-вывод записи в журналы транзакций
innodb_log_file_size : больший файл журнала уменьшает контрольные точки и записывает ввод / вывод
innodb_write_io_threads : служба операций записи в .ibdфайлы. Согласно документации MySQLConfiguring the Number of Background InnoDB I/O Threads , каждый поток может обрабатывать до 256 ожидающих запросов ввода-вывода. По умолчанию для MySQL 4, 8 для Percona Server. Макс 64
innodb_flush_log_at_trx_commit
- В случае сбоя и 0, и 2 могут потерять одну секунду данных.
- Компромисс состоит в том, что 0 и 2 увеличивают производительность записи.
- Я выбираю 0 вместо 2, потому что 0 сбрасывает буфер журнала InnoDB в журналы транзакций (ib_logfile0, ib_logfile1) один раз в секунду с фиксацией или без нее. Параметр 2 очищает буфер журнала InnoDB только при фиксации. Есть и другие преимущества установки 0, упомянутые @jynus, бывшим инструктором Percona .

Перезапустите MySQL, как это

service mysql restart --innodb-doublewrite=0

Это отключает буфер двойной записи InnoDB

Импортируйте ваши данные. Когда закончите, перезапустите MySQL нормально

service mysql restart

Это снова включает буфер двойной записи InnoDB

Попробуйте!

ПОБОЧНОЕ ПРИМЕЧАНИЕ: вам следует обновить систему до 5.6.21 для получения последних обновлений безопасности .

RolandoMySQLDBA
источник

1

Я сделал для него скрипт bash для linux, опустил некоторые значения для работы внутри vagrant

OZZIE

9

Вам действительно нужно восстановить всю базу данных? Если нет, мой 2с:

Вы можете извлечь конкретные таблицы, чтобы сделать ваше восстановление на «чанках». Что-то вроде этого:

zcat your-dump.gz.sql | sed -n -e '/DROP TABLE.*`TABLE_NAME`/,/UNLOCK TABLES/p' > table_name-dump.sql

Я сделал это один раз, и мне понадобилось около 10 минут, чтобы извлечь нужную таблицу - мое полное восстановление заняло 13 ~ 14 часов, с дампом 35 ГБ (gziped).

Параметр /pattern/,/pattern/pwith -nделает срез «между шаблонами» - включая их.

В любом случае, чтобы восстановить 35 ГБ, я использовал машину AWS EC2 (c3.8xlarge), установил Percona через yum (Centos) и просто добавил / изменил следующие строки my.cnf:

max_allowed_packet=256M
wait_timeout=30000

Я думаю, что цифры слишком высоки, но сработало для моей настройки.

Бруно Дж. Араужо
источник

5

Самый быстрый способ импортировать вашу базу данных - это скопировать файлы (.frm, .MYD, .MYI), если это MyISAM, прямо в / var / lib / mysql / «имя базы данных».

В противном случае вы можете попробовать: mysql > use database_name; \. /path/to/file.sql

Это еще один способ импортировать ваши данные.

Alex
источник

1

Одним из способов ускорить импорт является блокировка таблицы во время импорта. используйте параметр --add-locks для mysqldump.

mysqldump --add-drop-table --add-locks --database db > db.sql

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

mysqldump --opt --database db > db.sql

Если у вас есть другое устройство хранения на сервере, используйте его - копирование с одного устройства на другое - это способ ускорить передачу.

Вы также можете отфильтровать таблицы, которые не требуются с --ignore-table

pgee70
источник

MySQL любой способ импортировать огромный (32 ГБ) дамп sql быстрее?

Дополнительная информация / выводы

Ответы: