MySQLDump sur les performances de Windows dégradant au fil du temps

Question

J'ai un problème qui me pousse (et mon client) au mur. Ils exécutent MySQL sous Windows - J'ai hérité de cette plate-forme, je ne l'ai pas conçue et je suis passé à MSSQL sous Windows ou à la migration de l'instance MySQL vers une machine virtuelle * Nix n'est pas une option à ce stade.

Le serveur est un VM Windows, raisonnablement specced (4 vCores, 16 Go de RAM, etc.)

Dans un premier temps - ils avaient un seul disque pour le système d'exploitation, MySQL et l'emplacement de sauvegarde MySQL et ils devenaient incompatibles sauvegardes, à défaut régulièrement avec le message d'erreur:

mysqldump: Got errno 22 sur écriture

Finalement, nous avons résolu ce problème en déplaçant simplement la destination de sauvegarde vers un second disque virtuel (même si elle est est sur le même stockage sous-jacent réseau, nous avons cru que l'erreur ci-dessus était causée par l'OS sous-jacent)

Et la vie était bon ....

Pour environ 2-3 mois

Maintenant, nous avons un autre (mais mon instinct me dit connexe) question:

Le processus Dump MySQL prend de plus en plus de temps (au cours des 4 derniers jours, le temps pris pour la décharge a augmenté d'environ 30 minutes par sauvegarde). La base de données elle-même est un peu grande - 58 Go, mais la taille delta est seulement environ 100 mb par jour (et à moins que je manque quelque chose - cela ne devrait pas prendre 30 minutes supplémentaires pour décharger 100 Mo de données). Au départ, nous pensions qu'il s'agissait de l'E/S du réseau de stockage sous-jacente - mais dans le cadre du script de sauvegarde, une fois le fichier .SQL créé, il est compressé (à environ 8,5 Go) - et ce processus est très cohérent dans le temps pris - ce qui me conduit à ne pas soupçonner le disque I/O (comme ma présomption est que le temps Zip augmenterait aussi si c'était le cas).

le script que j'utiliser pour invoquer la sauvegarde est la suivante:

%mysqldumpexe% --user=%dbuser% --password=%dbpass% --single-transaction --databases %databases% --routines --force=true --max_allowed_packet=1G --triggers --log-error=%errorLogPath% > %backupfldr%FullBackup 

la version de mysqldump est C: \ Program Files \ MySQL \ MySQL 5.7 \ bin \ mysqldump.exe

maintenant pour compliquer les choses - je suis principalement un gars de Windows (donc j'ai une expérience MySQL limitée) et tous les gars de Linux au bureau ne le toucheront pas parce que c'est sous Windows.

Je suppose que la cause de l'augmentation du temps est qu'il y a quelque chose de funky avec les verrous de ligne (probablement en raison de l'application qui utilise l'instance MySQL) - mais je ne suis pas sûr.

Maintenant pour mes questions: Quelqu'un at-il connu quelque chose de similaire avec une augmentation progressive du temps pour un vidage de MySQL au fil du temps? Y at-il un moyen sur Windows pour surveiller nativement les performances de MySQLdump pour trouver où se trouvent les goulots d'étranglement/verrous? Existe-t-il une meilleure façon de faire une sauvegarde MySQL régulière sur une plate-forme Windows? Dois-je simplement dire au client qu'il n'est pas pris en charge et le faire migrer vers une plate-forme prise en charge? Dois-je simplement prononcer un mot de 4 lettres et aller au Pub et noyer mes peines?

Answer 1

Finalement trouvé le coupable était le réseau de stockage sous-jacent.