毛病的機械修睦後重啟，狂拉主庫binlog，招致收集成績的處理辦法。本站提示廣大學習愛好者：（毛病的機械修睦後重啟，狂拉主庫binlog，招致收集成績的處理辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是毛病的機械修睦後重啟，狂拉主庫binlog，招致收集成績的處理辦法正文
成績簡述：
一周前，有一台mysql辦事器產生硬件毛病，停機了。我們給專門擔任這塊的同窗提交了請求，他們擔任去報修這台辦事器。明天這台辦事器修睦後，他們將其開機啟動。辦事器上的4個mysql實例在開機後主動啟動，開端拉主庫的binlog。因為這台辦事器停機時光比擬久，日記丟的比擬多，狂拉主庫的binlog，招致主庫收集湧現成績。
景象：
起首，我們完整沒無意識到是由於一台壞失落的辦事重視啟拉主庫binlog招致的，由於我們壓根不曉得 這台辦事器甚麼情形，只曉得1周前，我們報修了1台辦事器。詳細甚麼情形，有無修睦，有無開機，我們完整不曉得。
在如許的情形下，溘然聽到收集的同窗說mysql有一台機械收集流量過年夜，招致營業感到很慢，總共連續了17分鐘。其實如許，是沒有多年夜眉目的。
排查：
檢查processlist、全日記、慢日記都沒有發明有甚麼成績。
檢查監控，發明那段時光的辦事器的讀IO突然降低。
經由過程檢查processlist的汗青記載，發明有一段時光，主從復制的用戶 狀況是 waiting for net，經由過程其IP發明該辦事器是1周前壞失落的一個slave辦事器。
結論：
這台辦事器上有4個實例，辦事器啟動後，mysql實例主動啟動，開端向主庫上拉binlog，每一個主庫天天的binlog量年夜概6G，4個實例1個禮拜年夜概160多G的binlog。
成績：
1、壞失落的辦事器甚麼時刻修睦，甚麼時刻開機，我們弗成控，也不曉得，也沒有存眷
2、這類案例實際上是很簡略、很典范的能夠形成影響或毛病的case，我們提早沒有對這個景象有警醒，固然曉得這是個很輕易湧現的成績，然則在我們的case中，完整沒有這方面的認識。是以招致該事宜產生
3、關於收集流量這塊，缺少有用監控
處理辦法：
1、一切辦事器，撤消開機主動啟動mysql，辦事器開機後，工資啟動實例，停slave。（如許，假如辦事器許多，能夠過於費事，暫且先如許記載上去，總比形成影響強）
2、認識到該成績，將該成績歸入防止成績的知識庫或任務手冊中去。
