Vider RAPIDEMENT une base de données au repos :
L'utilisation de l'option "-T" avec mysqldump génère de nombreux fichiers .sql et .txt dans le répertoire spécifié. C'est environ 50 % plus rapide pour le vidage de grandes tables qu'un seul fichier .sql avec des instructions INSERT (cela prend 1/3 de temps en moins).
De plus, il y a un énorme avantage lors de la restauration si vous pouvez charger plusieurs tables en parallèle et saturer plusieurs cœurs. Sur une boîte à 8 cœurs, cela pourrait représenter jusqu'à 8 fois la différence de temps pour restaurer le vidage, en plus des améliorations d'efficacité fournies par "-T". Étant donné que "-T" entraîne le stockage de chaque table dans un fichier séparé, il est plus facile de les charger en parallèle que de scinder un fichier .sql volumineux.
En poussant les stratégies ci-dessus à leur extrême logique, on pourrait créer un script pour vider une base de données largement en parallèle. Eh bien, c'est exactement ce que le Maakit mk-parallel-dump (voir http:/ /www.maatkit.org/doc/mk-parallel-dump.html ) et les outils mk-parallel-restore sont ; scripts perl qui effectuent plusieurs appels au programme mysqldump sous-jacent. Cependant, lorsque j'ai essayé de les utiliser, j'ai eu du mal à terminer la restauration sans erreurs de clé en double qui ne se produisaient pas avec les vidages vanille, alors gardez à l'esprit que votre kilométrage peut varier.
Dumping des données d'une base de données LIVE (sans interruption de service) :
Le commutateur --single-transaction est très utile pour effectuer un vidage d'une base de données active sans avoir à la mettre au repos ou effectuer un vidage d'une base de données esclave sans avoir à arrêter l'asservissement.
Malheureusement, -T n'est pas compatible avec --single-transaction, donc vous n'en obtenez qu'un.
Habituellement, prendre le vidage est beaucoup plus rapide que le restaurer. Il y a encore de la place pour un outil qui prend le fichier de vidage monolithique entrant et le divise en plusieurs morceaux à charger en parallèle. A ma connaissance, un tel outil n'existe pas encore.
Transférer le vidage sur le réseau est généralement une victoire
Pour écouter un vidage entrant sur une exécution d'hôte :
nc -l 7878 > mysql-dump.sql
Ensuite, sur votre hôte de base de données, exécutez
mysqldump $OPTS | nc myhost.mydomain.com 7878
Cela réduit les conflits pour les broches de disque sur le maître de l'écriture du vidage sur le disque, accélérant légèrement votre vidage (en supposant que le réseau est suffisamment rapide pour suivre le rythme, une hypothèse assez sûre pour deux hôtes dans le même centre de données). De plus, si vous construisez un nouvel esclave, cela évite d'avoir à transférer le fichier de vidage une fois qu'il est terminé.
Mises en garde - évidemment, vous devez disposer d'une bande passante réseau suffisante pour ne pas ralentir les choses de manière insupportable, et si la session TCP s'interrompt, vous devez tout recommencer, mais pour la plupart des vidages, ce n'est pas un problème majeur.
Enfin, je veux éclaircir un point de confusion commune.
Malgré la fréquence à laquelle vous voyez ces drapeaux dans les exemples et tutoriels mysqldump, ils sont superflus car ils sont activés par défaut :
--opt--add-drop-table--add-locks--create-options--disable-keys--extended-insert--lock-tables--quick--set-charset.
Depuis http://dev.mysql.com/doc/refman/ 5.1/fr/mysqldump.html :
Parmi ces comportements, "--quick" est l'un des plus importants (ignore la mise en cache de l'ensemble des résultats dans mysqld avant de transmettre la première ligne), et peut être avec "mysql" (qui n'active PAS --quick par défaut) pour accélérer considérablement les requêtes qui renvoient un ensemble de résultats volumineux (par exemple, vider toutes les lignes d'une grande table).
