У меня есть огромный дамп памяти объемом 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. Нужно ли увеличить это?

— 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 быстрее?

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