Як я можу пришвидшити відновлення MySQL з дамп-файлу?

28

Я відновлюю 30 Гб бази даних з файлу mysqldump до порожньої бази даних на новому сервері. При запуску SQL з дамп-файлу відновлення починається дуже швидко, а потім починає повільніше і повільніше. Зараз окремі вставки займають 15+ секунд. Таблиці - це в основному MyISAM з одним невеликим InnoDB. Сервер не має інших активних з'єднань. SHOW PROCESSLIST;показує лише вставку з відновлення (і показ самого списку процесів).

Хтось має ідеї, що може спричинити різке уповільнення?

Чи є змінні MySQL, які я можу змінити, щоб пришвидшити відновлення, поки воно прогресує?

backup restore mysql

— Дейв Форгак
джерело

Відредаговано для виправлення типів таблиць

— Дейв Форгач

26

Одне, що може сповільнити процес - це key_buffer_size , який є розміром буфера, який використовується для блоків індексів. Налаштуйте це щонайменше на 30% вашої оперативної пам’яті, або процес повторної індексації, ймовірно, буде надто повільним.

Для довідки, якщо ви використовували InnoDB та зовнішні ключі, ви також можете відключити перевірку іноземних ключів та повторно включити її в кінці (за допомогою SET FOREIGN_KEY_CHECKS=0та SET FOREIGN_KEY_CHECKS=1).

— Марко Рамос
джерело

1

Я знайшов дві речі: key_buffer_size було встановлено на 8 МБ, а в суміші з іноземними ключами була одна таблиця InnoDB. Збільшили розмір key_buffer_size до 1 Гб і тимчасово вимкнули перевірку іноземних ключів. Відновлення закінчилося за 5 хвилин. Спасибі!

— Дейв Forgac

Оце Так! Радий, що це допомогло :)

— Марко Рамос

2

Я щойно помітив, що я набрав 5 хвилин. Я впевнений, що це було більше 50 хвилин, але все-таки розумніший ;-)

— Дейв Forgac

5

key_buffer_size призначений для MYISAM.

— Фернандо Фабреті

@FernandoFabreti - це важливий момент для багатьох читачів, але в ОП уточнили, що в основному вони були MyISAM

— mc0e

22

Це посилання показує, що можна зробити, щоб прискорити процес відновлення.

http://dev.mysql.com/doc/refman/5.5/uk/optimizing-innodb-bulk-data-loading.html

Можна поставити команди у верхній частині дамп-файлу

SET @OLD_AUTOCOMMIT=@@AUTOCOMMIT, AUTOCOMMIT = 0;
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS = 0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS = 0;

І поставте ці заяви в кінець файлу дампа

SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
SET AUTOCOMMIT = @OLD_AUTOCOMMIT;
COMMIT;

Це працювало для мене. Щасливе відновлення :-)

— Дхармеш Кравець
джерело

8

Це допомогло зовсім небагато. Замість того, щоб редагувати файл, я створив pre.sql та post.sql із фрагментів вище та використав це для відновлення db:cat pre.sql dump.sql post.sql | mysql ...

— Джейсон Р. Кумбс

1

Єдина причина, по якій я можу зрозуміти, чому відновлення поступово сповільниться, - це індексація. Дослідіть відключення індексації до кінця, а потім нехай це зробить всю партію відразу.

— Джон Гарденєр
джерело

1

Якщо у вас є фізична копія дамп-файлу (каталог DB), ви можете просто скопіювати його на новий сервер, якщо новий сервер має таку ж версію MySQL, і він буде добре працювати. Це добре працює з MyISAM, і я вважаю, що це краще, ніж відновлення даних на основі логічного дамп-файлу SQL.

— usef_ksa
джерело

0

якщо у вас є кілька таблиць, ви можете скористатися mk-паралельним відновленням .

— pQd
джерело

Це тепер застаріле і його слід використовувати лише для відновлення тестових даних, а не для відновлення фактичних резервних копій.

— svandragt

0

Це зробить:

mysql --init-command = "Встановити сесію FOREIGN_KEY_CHECKS = 0; SET UNIQUE_CHECKS = 0;" -u root -p <Backup_Database.mysql

— Матіс
джерело

-1

Я вам запропонував,

Перевірте свої таблиці: чи є в ньому тригери? Очистити всі тригери
SET: AUTOCOMMIT=0, UNIQUE_CHECKS=0, FOREIGN_KEY_CHECKS=0( І НЕ ЗАБУДЬТЕ відкотити ЦЕ ЗМІНИ )
ВИКОРИСТОВУЙТЕ КОМАНДАЛЬНУ ЛІКУ mysql -u root -pPasss requests < mydb.sql
Перевірте розмір файлу бази даних

Щасти

— Ферхат КОÇЕР
джерело