2013应M公司要求，产品线迁移。11号停线、备份所有数据库，上传到异地，按照策略本地保留一个备份集。

利用FTP将备份集上传到文件服务器500GB文件、8M/S的速率预测在17小时可完成；由于时间比较紧17:40开始上传，设置好后下班回家.....

晚上23:00一线兄弟电话，反应说所有产线扫描慢，分析DB LOCK、TOP SQL并没有问题...让一线支援兄弟ping包发现有丢包现象，根据这个现象以为找到原因，紧急电话network兄弟；network兄弟监控DB服务器网卡流量并未发现异常、流量稍微有所下降，交换机log亦为发现异动现象；问题好似陷入僵局...

在次跟一线兄弟确认异常事件段，反映到从18:00点开始有扫描慢现象、由于此时段已处于下班时间段，支援兄弟也未太在意.....22:30晚餐之后，生产主管视察发现该问题、严责IT查找原因，所以出现上述紧急动员。

根据这一事件段，大概猜测为自己的异机传送、赶紧停掉ftp上传。折腾到24:00生产恢复.....汗!

事后检讨该issue:

是DBA失误不该备份传送、一线兄弟未及时反馈信息、还是network主干线网络架构垃圾。公司的策略是问题最终由哪个部门解决、责任就是哪个部门的，MMD...

总之发现一隐形炸弹，请network兄弟检查网络主干线，升级！

ITPub博客

主干网流量大引发的扫描慢问题

最新文章