Mysqldump tout le monde l’utilise pour exporter des données MySQL. Cependant, le volume de données généré par Mysqldump peut rapidement devenir considérable. Il est très utile de pouvoir compresser ces dump pour réduire leur taille, mais sans avoir des pertes de performances inutiles. J’ai mesuré l’impact de différentes méthodes de compression gzip, pigz, xz et pixz. Afin de mettre en lumière les performances de Mysqldump et les gains en termes d’espace de stockage.

Protocole de test

  • Une base de données de dump brute de 7Go avec innodb a été utilisée
  • Cela tourne sous MySQL 5.7, c’est une veille app comme il en reste beaucoup. Il faudra tester également avec MySQL 8.0.
  • VM sous ESXi avec 12 vCPU intel Xeon qui ont 5ans.

Compressions utilisées

La compression de texte se passant mal pour bzip2, je l’ai d’office exclus. J’envisage donc Gzip et XZ. Il y a le monde un seul thread avec :

  • Gzip
  • XZ

Et multi-thread avec :

  • pigz
  • pixz

Quand il n’y a plus de gain selon le niveau de compression (pouvant aller de 1 à 9), j’arrête les tests inutiles.

Tableau benchmark compression Mysqldump

Pour Gzip, il n’y a plus de gain de taille après une compression de 7.

Pour XZ, il n’y a plus de gain de taille après un niveau de 5.

AlgorithmeProcCompressionDécompression
NiveauTailleRatioTemps (min)VitesseTempsVitesse
(Mo)(Mo/s)(min)(Mo/s)
gzip13129118,06%2,8242,301,9361,62
5114315,99%3,7032,201,5278,55
7111515,60%5,5321,531,4383,12
pigz23128718,01%1,6273,691,6572,20
5114315,99%1,9860,071,5576,86
7111515,60%2,7343,591,5776,04
33128718,01%1,3886,121,3886,12
5114315,99%2,1754,981,5377,70
7111515,60%2,3051,801,674,46
43128718,01%1,4582,161,4085,10
5114315,99%1,6372,941,6273,69
7111515,60%1,8763,821,5576,86
 
xz1184111,77%8,5213,992,449,64
377110,79%24,254,911,7368,73
56809,51%56,132,121,6372,94
pixz2184111,77%8,0714,771,6273,69
377110,79%17,326,881,7269,40
3184111,77%9,0713,143,1338,02
377110,79%26,904,433,0339,27
4184111,77%8,8213,511,9860,07
377110,79%19,226,202,0059,57
476810,74%31,033,841,9760,58
56809,51%47,732,501,9262,16
5184111,77%8,1214,682,9839,93
377110,79%17,386,853,0239,49
6184111,77%8,0014,892,5846,12
377110,79%17,086,972,0757,65

Résultats de compression Mysqldump

Le meilleur temps qui ne consomme pas trop de ressources, c’est pigz avec 4 threads et une compression de niveau 3. La compression est très bonne un niveau 7, mais 3% de taille en moins pour 28% de temps en plus, est-ce utile ? Vous savez quoi utilise pour gagner 5,5x l’espace disque en impactant très peu la charge CPU.

Comme vous pouvez le voir, il y a deux options si vous avez besoin d’archiver à long terme beaucoup de données :

  • soit vous cherchez la rapidité et avoir un gain important de place par rapport à gzip et vous utiliserez pixz avec un niveau 1 de compression et 2 processus.
  • soit vous cherchez une compression importante et vous utiliserez pixz avec un niveau 3 de compression et 5 processus. Un niveau plus haut que 3 ne sert à rien, trop de temps perdu pour un gain minime de compression, comme on peut le voir avec un niveau 5

Si vous avez une architecture master/slave MySQL, je vous conseille de le faire sur votre slave pour éviter les lock tables sur votre master.

J’ai effectué un comparatif également pour les backups compressés d’XtraBackup.

Articles relatifs :

Summary
Mysqldump benchmark compression
Article Name
Mysqldump benchmark compression
Description
L'étude compare les performances Mysqldump avec différentes méthodes de compression gzip, pigz, xz, pixz pour optimiser l'espace de stockage
Author