我有一个问题正在推动我（和我的客户）走上墙。他们在Windows上运行MySQL - 我继承了这个平台，我没有设计它，在Windows上更改为MSSQL或者将MySQL实例迁移到* Nix VM不是现阶段的选择。
服务器是单个Windows VM，合理地推测（4个vCores，16 Gb RAM等）
最初 - 他们有一个用于操作系统，MySQL和MySQL备份位置的磁盘，他们的备份不一致，经常出现错误消息：
mysqldump：写错了22
最终我们通过简单地将备份目标移动到第二个虚拟磁盘来解决这个问题（即使它位于相同的底层存储网络上，我们认为上述错误是由底层操作系统引起的）
生活很美好......
大约2-3个月
现在我们有一个不同的（但我的直觉告诉我相关）问题：
MySQL转储过程花费的时间越来越长（过去4天，转储每个备份增加了大约30分钟）。
数据库本身有点大 - 58 Gb，但是大小的delta每天只有大约100 mb（除非我遗漏了一些东西 - 它不应该花费30分钟来转储100 MB的数据）
最初我们认为这是底层存储网络I / O - 但是作为备份脚本的一部分，一旦创建.SQL文件，它就会被压缩（大约8.5 Gb） - 这个过程非常一致在所花费的时间 - 这导致我不怀疑磁盘I / O（因为我的推测是，如果是这种情况，Zip时间也会增加）。
我用来调用备份的脚本是：
%mysqldumpexe% --user=%dbuser% --password=%dbpass% --single-transaction --databases %databases% --routines --force=true --max_allowed_packet=1G --triggers --log-error=%errorLogPath% > %backupfldr%FullBackup
MySQLDump的版本是C：\ Program Files \ MySQL \ MySQL Server 5.7 \ bin \ mysqldump.exe
现在要解决问题 - 我主要是Windows用户（因此MySQL经验有限），办公室的所有Linux用户都不会触摸它，因为它在Windows上。
我怀疑增加时间的原因是行锁存在一些时髦的事情（可能是由于使用MySQL实例的应用程序） - 但我不确定。
现在我的问题：随着时间的推移，有没有人经历过类似的MySQL转储时间的逐渐增加？ 有没有办法在Windows上本地监视MySQLdump的性能，以找到瓶颈/锁定的位置？ 有没有更好的方法在Windows平台上进行常规MySQL备份？ 我应该告诉客户它是否不受支持并将其迁移到支持的平台？ 我应该简单地说出一个4个字母的单词并去酒吧并淹没我的悲伤吗？
答案 0 :(得分：0)
最终发现罪魁祸首是底层存储网络。