У мене є цей величезний дамп у 32 ГБ SQL, який мені потрібно імпортувати в MySQL. Мені раніше не довелося імпортувати такий величезний дамп SQL. Я робив звичайне:

mysql -uroot dbname < dbname.sql

Це забирає занадто довго. Є таблиця з приблизно 300 мільйонами рядків, вона отримала до 1,5 мільйона приблизно за 3 години. Отже, здається, що вся справа зайняла б 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 = 16М та innodb_log_buffer_size = 8М. Чи потрібно їх збільшувати?

— SBhojani
джерело

Чи можете ви додати більш швидкі компоненти до сервера, а саме більше оперативної пам’яті та SSD-пам’яті?

@Bert сервер має 8 ГБ оперативної пам’яті, більшість з яких просто не використовується. Неможливо також додати більше пам’яті. Як би це допомогло? Чи справді операції запису такі повільні?

Яке вузьке місце? Чи є CPU Core прив'язаним?

— Кріс С

@ChrisS ні, використання процесора становить від 3 до 4%. Я не впевнений, що таке вузьке місце. Я думаю, що це показники. Як можна було б знайти / підтвердити вузьке місце?

1

Якщо у вас є sql, чи можете ви відредагувати оператори створення індексу та побачити, чи йде воно швидше? як тільки ви імпортуєте дані, вам потрібно буде відтворити їх

84

Вадим Ткаченко Перкона створив це чудове живописне представлення 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, колишнім інструктором Перкона .

Перезапустіть mysql, як це

service mysql restart --innodb-doublewrite=0

Це вимикає подвійний запис буфера InnoDB

Імпортуйте свої дані. Після закінчення перезапустіть mysql нормально

service mysql restart

Це повторно використовує подвійний запис буфера InnoDB

Спробувати !!!

БІЛЬНА ПРИМІТКА: Вам слід оновити до 5.6.21 для останніх виправлень безпеки .

— RolandoMySQLDBA
джерело

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

— 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/pЗ -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

Це ще один спосіб імпорту ваших даних.

— Олексій
джерело

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 дамп?

Детальна інформація / висновки