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博客 ” ,链接:http://blog.itpub.net/24867586/viewspace-752931/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/24867586/viewspace-752931/