Почему крайне долго импортируется дамп и как это ускорить?

Question

[Crash]

Импортирую локально дамп, который весит всего лишь 4 Гб, уже 5-й час в MySQL Workbench. Работа стоит(

У меня HDD на 1 терабайт, с SSD конечно было бы быстрее. ОС Ubuntu 20.04, ОЗУ 8Гб.

Можно ли как-то ускорить процесс, не меняя тип накопителя? Подскажите пожалуйста как решить.

Comments

[Everything_is_not_so_bad]

mysql работает локально? Если удалённо, то через интернет? VPN? SSH?

[Crash]

Роман Мирр, да, локально. Дополню вопрос.

[Everything_is_not_so_bad]

Стоит предвартельно посмотреть при помощи iotop происходит ли чтение данных в Mysql Workbench или застопорилось.

[Crash]

Роман Мирр, сделал вывод этой командой, есть меняющиеся данные в колонке DISK_WRITE для команды mysqld (несколько сот килобайт в секунду). Процесс идет, насколько я понял. Жесткий диск тоже шебуршит)

[Everything_is_not_so_bad]

Crash, дамп пишется со сжатием или без? Можно посмотреть на предварительный размер дампа в целевой директории и тогда оценить время окончания.

[Crash]

Роман Мирр, насколько я понял без сжатия, вот такую команду вывел воркбенч:

12:01:10 Restoring /home/oleg/Загрузки/phalcon_sklad 2020.06.10.sql
Running: /snap/mysql-workbench-community/6/usr/lib/mysql-workbench/mysql --defaults-file="/tmp/tmpvg5p1z/extraparams.cnf" --protocol=tcp --host=localhost --user=root --port=3306 --default-character-set=utf8 --comments --database=sk_phalcon_api < "/home/oleg/Загрузки/phalcon_sklad 2020.06.10.sql"

[Everything_is_not_so_bad]

Лентюй, блокировки в СУБД?

[Crash]

Лентюй, процесс идет, в колонке State

copy to tmp table

[Crash]

Лентюй, да вроде нет. Дамп если что завершился. Всем спасибо! Впредь буду делать немного по-другому.

Answer 1

[d-stream]

Можно сделать примерно такое (говорят сам mysql тоже умеет):
- выкусить (отложить в сторонку) из дампа все что касается ключей, индексов, констрэйнов
- залить остальное
- применить выкушенное

как минимум это позволит в процессе заполнения таблиц "не отвлекать" субд на постоянное обновление индексов, проверки консистентности и т.п.

Answer 2

[Everything_is_not_so_bad]

Попробовать создать дамп mysqldump с опциями --opt --quick затем| gzip > dump.sql.gz
Можно установить утилиту pv и тогда будет видна скорость получения данных и объём переданных данных.

mysqldump ... | pv | gzip > file
желательно перенаправить на отдельный накопитель.

Comments

[Crash]

дамп не мой, заставить пересоздать вряд ли получится) Отдельного накопителя под рукой тоже к сожалению нет. Можно ли сейчас как-то помониторить текущий процесс дампа? Есть какие-нибудь встроенные команды для этого? Дамп импортирую через интерфейс Воркбенча. Устал ждать, прогресс бар тоже ничего не показывает(

[Crash]

увидел выше упоминание iotop, сейчас попробую

[Everything_is_not_so_bad]

Crash, застопорившийся дамп имеет смысл прервать и тогда можно создать как я написал.

[Crash]

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

[Everything_is_not_so_bad]

Crash, могу ошибаться, но, по-моему, никакого влияния не должно оказывать.

Answer 3

[Vitaly Karasik]

Не меняя диск и тип дампа - остается только настроить my.cnf.
А проверить сколько осталось - два варианта, первый и проще и "легче" для системы:
- посмотреть сколько места занимает база на вашем диске
- в MySQL - посмотреть сколько таблиц и сколько записей в больших таблицах.

Comments

[Crash]

как именно можно настроить my.cnf?

[Vitaly Karasik]

innodb_buffer_pool_size = 70% RAM
innodb_doublewrite=0
innodb_flush_log_at_trx_commit=0

Вот тут проверки с похожей базой https://www.percona.com/blog/2018/02/22/restore-my....

Но для начала я бы проверил сколько восстановилось - может и нет смысла все заново начинать.

Answer 4

[Пума Тайланд]

Да в память его засуньте и будет быстро, как варианты выключить индексы если в этом дело, сами данные такого объема быстро импортируются