梳理一個timeline
預估20億，單端口閥值約5億和業務溝通現在總17億，出現個别端口達到容量瓶頸，出現滾表現象
- 預計7：17 收到11546，11547 報警。 磁盤報警10.75.22.238：/data1 = 100.00% ， 磁盤滿發現是11547 dump檔案導緻執行個體crash
- 臨時删除11547 dump檔案
- 嘗試啟動 11546 執行個體，失敗原因aof損壞，修複aof檔案失敗
- 8:26 進行切主：查找從庫，dsp，dpadmin 均特别卡
- 9:00 變更完成主從但是由于dpamdin問題并未上線，但以周知相關業務負責同學切主庫域名
- 10:35變更115456，11547主庫域名
- 11：40 業務回報一個端口資料為空，聯系同僚一起分析處理
- 滾表資料落地磁盤，和業務溝通後用rdb恢複，損失小部分資料
記一次counterservice 故障處理及恢複的時間線 - 需要用統一的rdb檔案資料傳輸，然後域名操作不友善
- 13:12 11547 恢複
- 14:25 回報11561 端口 和11547 端口
記一次counterservice 故障處理及恢複的時間線 - 選用一個新主 将table num 調整到4 ，然後其他從庫以新主的rdb 為主恢複
- 15：18 左右恢複
####總結後續改善建議，并落地實施
- 2個table，使用率85%，滾表dump資料，計算方式修正報警
- 添加不再dump機制
- 統計所有的2個table的counterservice執行個體，并确定是不是需要滾表； 臨時處了解決方式：滾動率調高—》或者擴容 ，更新
轉載于:https://my.oschina.net/tingting1127723365/blog/846445