一周前，有一臺mysql服務器發(fā)生硬件故障，停機了。我們給專門負責這塊的同學提交了申請，他們負責去報修這臺服務器。今天這臺服務器修好后，他們將其開機啟動。服務器上的4個mysql實例在開機后自動啟動，開始拉主庫的binlog。由于這臺服務器停機時間比較久，日志丟的比較多，狂拉主庫的binlog，導致主庫網(wǎng)絡出現(xiàn)問題。

現(xiàn)象：
首先，我們完全沒有意識到是因為一臺壞掉的服務器重啟拉主庫binlog導致的，因為我們壓根不知道這臺服務器什么情況，只知道1周前，我們報修了1臺服務器。具體什么情況，有沒有修好，有沒有開機，我們完全不知道。

在這樣的情況下，忽然聽到網(wǎng)絡的同學說mysql有一臺機器網(wǎng)絡流量過大，導致業(yè)務感覺很慢，總共持續(xù)了17分鐘。其實這樣，是沒有多大頭緒的。

排查：

查看processlist、全日志、慢日志都沒有發(fā)現(xiàn)有什么問題。

查看監(jiān)控，發(fā)現(xiàn)那段時間的服務器的讀IO驟然升高。

通過查看processlist的歷史記錄，發(fā)現(xiàn)有一段時間，主從復制的用戶狀態(tài)是 waiting for net，通過其IP發(fā)現(xiàn)該服務器是1周前壞掉的一個slave服務器。

結論：

這臺服務器上有4個實例，服務器啟動后，mysql實例自動啟動，開始向主庫上拉binlog，每個主庫每天的binlog量大概6G，4個實例1個星期大概160多G的binlog。

問題：

1、壞掉的服務器什么時候修好，什么時候開機，我們不可控，也不知道，也沒有關注

2、這種案例其實是很簡單、很典型的可能造成影響或故障的case，我們提前沒有對這個現(xiàn)象有警覺，雖然知道這是個很容易出現(xiàn)的問題，但是在我們的case中，完全沒有這方面的意識。因此導致該事件發(fā)生

3、對于網(wǎng)絡流量這塊，缺乏有效監(jiān)控