2009-07-10 3 views
18

Possible en double:
Speeding up mysql dumps and importsExiste-t-il un moyen plus rapide de charger mysqldumps?

mysqldump est raisonnablement rapide, mais les décharges d'une base de données de taille moyenne (20-30 mégas) prendre plusieurs minutes pour charger en utilisant mysql my_database < my_dump_file.sql

Y at-il des paramètres mysql que je peux régler pour accélérer la charge? Existe-t-il un meilleur moyen de charger les données sauvegardées?

J'ai expérimenté l'utilisation de l'utilitaire mysqlimport avec des vidages CSV. Ceux-ci se chargent légèrement - mais pas sensiblement - plus rapidement. Je suis tenté de copier des fichiers de base de données bruts, mais cela semble être une mauvaise idée.

+0

... Je FYI juste eu un raid 5 disque défaillant, ce qui a causé des performances vraiment mauvais avec MySQL restauration . Ce qui prenait normalement 40 minutes poussait 24 heures. Juste pour référence. – gahooa

Répondre

5
+0

Merci, c'est exactement ce que je cherchais! –

+13

La description indique qu'il y a des bugs dans le logiciel et ne doit PAS être utilisé pour des sauvegardes ou des données importantes! Dommage ... Je me demande si je peux juste lancer plusieurs mysqldumps en parallèle sur différentes tables pour obtenir une accélération? – davr

5

Assurez-vous que vous utilisez l'option --opt pour mysqldump lors du vidage. Cela utilisera la syntaxe d'insertion en bloc, retarder les mises à jour clés, etc ...


Si vous utilisez uniquement les tables MyISAM, vous pouvez en toute sécurité les copier en arrêtant le serveur, de les copier sur un serveur arrêté, et à partir de ça.

Si vous ne voulez pas arrêter le serveur d'origine, vous pouvez suivre ceci:

  1. verrouilliez de lecture sur toutes les tables
  2. Rincer toutes les tables
  3. Copiez les fichiers
  4. Unlock les tables

Mais je suis sûr que votre serveur de copie vers doit être arrêté lorsque vous les mettez en place.

+0

En fait, c'est ce que mysqlhotcopy fait – aldrinleal

+0

Malheureusement, je n'ai qu'un seul vote à donner. En changeant la façon dont j'effectuais mysqldump, en utilisant l'option --opt comme vous l'avez suggéré, j'ai rasé 5 heures de mon importation! – Nate

+0

@Nate Il doit y avoir d'autres raisons pour lesquelles votre importation est maintenant plus rapide, car '--opt' est activé par défaut dans mysqldump. Il en a été ainsi au moins depuis la version 5.5 (2010). – dr01

1

Il existe une méthode d'utilisation des instantanés LVM pour la sauvegarde et la restauration qui pourrait être une option intéressante pour vous. Au lieu de faire un mysqldump, pensez à utiliser LVM pour prendre des instantanés de vos répertoires de données MySQL. L'utilisation d'instantanés LVM vous permet d'avoir une capacité de sauvegarde presque en temps réel, la prise en charge de tous les moteurs de stockage et une récupération incroyablement rapide. Pour citer le lien ci-dessous,

"Le temps de récupération est aussi rapide que la restauration des données et la reprise après incident standard de MySQL, et il peut encore être réduit."

http://www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-and-replication-setup/

4

Êtes-vous sûr que les données est sain d'esprit, et il n'y a pas de problèmes de performance ou système de fichiers système? Plusieurs minutes pour une base de données de 20-30 Mo sont longues. Je suis sur un MacBook avec 2 Go de RAM, une HD de 320 Go et le processeur standard de 2,1 GHz. J'ai saisi une de mes bases de données pour un benchmark rapide:

gavinlaking$ du -sm 2009-07-12.glis 
74 2009-07-12.glis 
gavinlaking$ mysql -pxxx -e "drop database glis" 
gavinlaking$ mysql -pxxx -e "create database glis" 
gavinlaking$ time mysql -pxxx glis < 2009-07-12.glis 

real 0m17.009s 
user 0m2.021s 
sys 0m0.301s 

17 secondes pour un fichier de 74 mégaoctets. Cela me semble assez accrocheur. Même s'il était 4 fois plus gros (environ 300 mégaoctets), il finit en moins de 70 secondes.

25

En supposant que vous utilisez InnoDB ...

J'étais dans la situation d'avoir un tas de fichiers de sortie de mysqldump existants que je voulais importer dans un délai raisonnable. Les tables (une par fichier) mesuraient environ 500 Mo et contenaient environ 5 000 000 de lignes de données chacune. En utilisant les paramètres suivants, j'ai été en mesure de réduire le temps d'insertion de 32 minutes à moins de 3 minutes.

innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 256M
innodb_flush_method = O_DIRECT

Vous aurez également besoin d'avoir un cadre innodb_buffer_pool_size assez grande. Parce que mes insertions étaient uniques, j'ai inversé les réglages par la suite. Si vous continuez à les utiliser à long terme, assurez-vous de savoir ce qu'ils font.

J'ai trouvé la suggestion d'utiliser ces paramètres sur Cedric Nilly's blog et l'explication détaillée pour chacun des paramètres peut être trouvée dans le MySQL documentation.

+0

C'est la deuxième fois que j'utilise cette méthode. Dans les deux cas (différentes bases de données), le temps d'importation a été réduit de quelques heures à quelques minutes. Merci! – lepe

+0

J'ai récemment dû faire cela pour une table simple de ~ 8 colonnes et surtout des données int. Avant d'appliquer ceux-ci, je recevais environ ~ 30 inserts/s (index désactivés). Après le changement, je recevais ~ 600 inserts/s. La plus grande victoire vient de la définition de innodb_flush_log_at_trx_commit de '1' (par défaut) à '2', qui vide les écritures à journaliser chaque seconde, et non à chaque transaction (qui est après chaque insertion lorsqu'un autocommit est vrai. – Adil

+0

Pouvez-vous expliquer ce qui se passe lors de l'édition de ces valeurs? Pour nous de comprendre. Je viens de l'utiliser et la vitesse est impressionnante. – reignsly

Questions connexes