web-dev-qa-db-fra.com

MySQL est-il possible d'importer un énorme dump sql (32 Go) plus rapidement?

J'ai cet énorme vidage SQL de 32 Go que je dois importer dans MySQL. Je n'ai jamais eu à importer un énorme vidage SQL auparavant. J'ai fait comme d'habitude:

mysql -uroot dbname < dbname.sql

Cela prend trop de temps. Il y a une table avec environ 300 millions de lignes, elle est passée à 1,5 million en environ 3 heures. Il semble donc que le tout prendrait 600 heures (soit 24 jours) et n'est pas pratique. Ma question est donc la suivante: existe-t-il un moyen plus rapide de le faire?

Autres informations/résultats

  1. Les tables sont toutes InnoDB et aucune clé étrangère n'est définie. Il existe cependant de nombreux index.
  2. Je n'ai pas accès au serveur et à la base de données d'origine, je ne peux donc pas faire une nouvelle sauvegarde ou faire une copie "à chaud", etc.
  3. Réglage innodb_flush_log_at_trx_commit = 2 comme suggéré ici ne semble apporter aucune amélioration (clairement visible/exponentielle).
  4. Statistiques du serveur lors de l'importation (depuis MySQL Workbench): https://imgflip.com/gif/ed0c8 .
  5. La version MySQL est la communauté 5.6.20.
  6. innodb_buffer_pool_size = 16M et innodb_log_buffer_size = 8M. Dois-je les augmenter?
mysqlbackupinnodbmysqldump
81
SBhojani

Vadim Tkachenko de Percona a fait cette belle représentation picturale d'InnoDB

InnoDB Architecture

Vous devez absolument changer ce qui suit

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

Pourquoi ces paramètres?

Redémarrez mysql comme ceci

service mysql restart --innodb-doublewrite=0

Cela désactive le double tampon d'écriture InnoDB

Importez vos données. Une fois terminé, redémarrez mysql normalement

service mysql restart

Cela réactive le double tampon d'écriture InnoDB

Essaie !!!

NOTE LATÉRALE: Vous devez mettre à niveau vers 5.6.21 pour les derniers correctifs de sécurité .

97
RolandoMySQLDBA

Avez-vous vraiment besoin de restaurer la base de données entière? Sinon, mon 2c:

Vous pouvez extraire des tables spécifiques pour effectuer votre restauration sur des "morceaux". Quelque chose comme ça:

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

Je l'ai fait une fois et il m'a fallu environ 10 minutes pour extraire la table dont j'avais besoin - ma restauration complète a pris de 13 à 14 heures, avec un vidage de 35 Go (gzipé).

Le /pattern/,/pattern/p avec le -n le paramètre crée une tranche "entre les motifs" - en les incluant.

Quoi qu'il en soit, pour restaurer les 35 Go, j'ai utilisé une machine AWS EC2 (c3.8xlarge), installé Percona via yum (Centos) et juste ajouté/modifié les lignes suivantes sur my.cnf:

max_allowed_packet=256M
wait_timeout=30000

Je pense que les chiffres sont beaucoup trop élevés, mais cela a fonctionné pour ma configuration.

13
Bruno J. Araujo

Le moyen le plus rapide d'importer votre base de données est de copier les fichiers (.frm, .MYD, .MYI) de MyISAM, directement dans/var/lib/mysql/"nom de la base de données".

Sinon, vous pouvez essayer: mysql > use database_name; \. /path/to/file.sql

C'est une autre façon d'importer vos données.

6
Alex

une façon d'aider à accélérer l'importation consiste à verrouiller la table lors de l'importation. utilisez l'option --add-locks pour mysqldump.

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

ou vous pouvez activer certains paramètres utiles avec - - opt cela active un tas de choses utiles pour le vidage.

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

Si vous avez un autre périphérique de stockage sur le serveur, utilisez-le - la copie d'un périphérique à un autre est un moyen d'accélérer les transferts.

vous pouvez également filtrer les tables qui ne sont pas nécessaires avec - ignore-table

1
pgee70