J'ai cet énorme dump SQL de 32 Go que j'ai besoin d'importer dans MySQL. Je n'avais pas eu besoin d'importer un tel dump SQL auparavant. J'ai fait l'habituel:

mysql -uroot dbname < dbname.sql

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

Informations complémentaires / 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 d'origine ni à la base de données, je ne peux donc pas effectuer de nouvelle sauvegarde, ni effectuer une copie "à chaud", etc.
3. Le réglage innodb_flush_log_at_trx_commit = 2tel que suggéré ici ne semble entraîner aucune amélioration (clairement visible / exponentielle).
4. Statistiques du serveur lors de l'importation (à partir de MySQL Workbench): https://imgflip.com/gif/ed0c8 .
5. La version de MySQL est la communauté 5.6.20.
6. innodb_buffer_pool_size = 16M et innodb_log_buffer_size = 8M. Dois-je les augmenter?

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

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?

• innodb_buffer_pool_size mettra en cache les données lues fréquemment
• innodb_log_buffer_size : Une mémoire tampon plus grande réduit les entrées / sorties en écriture dans les journaux de transaction
• innodb_log_file_size : un fichier journal plus volumineux réduit les points de contrôle et écrit les E / S
• innodb_write_io_threads : Opérations d'écriture de service dans des .ibdfichiers. Selon la documentation MySQLConfiguring the Number of Background InnoDB I/O Threads , chaque thread peut gérer jusqu'à 256 requêtes d'E / S en attente. La valeur par défaut pour MySQL est 4, 8 pour Percona Server. Max a 64 ans.
• innodb_flush_log_at_trx_commit
  • En cas de blocage, les valeurs 0 et 2 peuvent perdre une seconde de données.
  • Le compromis est que 0 et 2 augmentent les performances en écriture.
  • J'ai choisi 0 sur 2 car 0 vide la mémoire tampon du journal InnoDB dans les journaux des transactions (ib_logfile0, ib_logfile1) une fois par seconde, avec ou sans validation. Le paramètre 2 vide la mémoire tampon du journal InnoDB uniquement lors de la validation. Le réglage 0 mentionné par @jynus, un ancien instructeur de Percona, présente d’autres avantages .

Redémarrez mysql comme ceci

service mysql restart --innodb-doublewrite=0

Ceci désactive le tampon d’écriture double InnoDB

Importez vos données. Quand cela est fait, redémarrez mysql normalement

service mysql restart

Ceci réactive le tampon d’écriture double InnoDB

Essaie !!!

NOTE LATÉRALE : Vous devez effectuer une mise à niveau vers la version 5.6.21 pour obtenir les derniers correctifs de sécurité .

Avez-vous vraiment besoin que toute la base de données soit restaurée? Si vous ne le faites pas, 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 a fallu environ 10 minutes pour extraire la table dont j'avais besoin - ma restauration complète a pris 13 à 14 heures, avec un dump de 35 Go (gziped).

Le paramètre /pattern/,/pattern/pwith -ncrée une découpe "entre les patterns" - 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 ajouté / modifié les lignes suivantes my.cnf:

max_allowed_packet=256M
wait_timeout=30000

Je pense que les chiffres sont beaucoup trop élevés, mais ont fonctionné pour mon installation.

Le moyen le plus rapide d'importer votre base de données est de copier les fichiers (.frm, .MYD, .MYI) si MyISAM, directement dans le fichier / 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.

Un moyen 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 dump.

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