記錄一次線上嚴重事故（變更表結構導致商城系統宕機）

事件：

早上 7點左右 ，**表更新了**字段精度(500萬級)，導致**系統系統不可用

**系統從 7點到11點間不可用 （嚴重級）

報表系統整天不可用 （嚴重級）

早上9：30 點左右，**表重新建立索引，**系統恢復

報表系統同步一直到12點發現還一直卡著，然後找阿里雲技術解決，一直到20：00 才ok

刷表結構導致**系統不可用原因： 刷表結構後，表的所有索引需要重建，而polardb資料庫建立從庫建立索引失效，price 表每次全表掃瞄，查詢時間平均 13秒，

由於這個張表的查詢時間過長導致所有的執行緒被耗盡，k8s 做健康檢查的時候沒有執行緒響應，k8s認為服務掛了（10秒未響應），kill掉這個應用

報表同步問題：頻繁修改dts同步表結構導致dts卡死，原因是 adb 資料庫快取過小，後來找阿里雲那邊搞好的

問題總結：

之後我們需要嚴格對待表結構變更問題，之前資料量比較小基本變更一下表結構幾秒鐘就ok了，目前我們有些表的資料已經是千萬級規模了，很容易出現鎖表。

解決方案：

以後所有的線上資料運維必須走dms工具

涉及表結構變更的發版要提前做好預案

事件：

早上 9：40 左右 ，因為要同步adb表結構需要刪表，操作失誤誤把線上product庫刪掉了

影響：

整個系統從9：40到11點間不可用 （嚴重級）

事故解決過程：

1.恢復備份資料，耗時1小時左右 2.驗證並補全錯誤資料

原因分析：

本次事故主要是人為操作失誤造成

問題總結：

為防止人為操作失誤 最好的辦法是從流程上來解決 ， 為此以後所有的資料上線必須走dms審核工具，並且要做好資料備份，不允許直接運算元據庫

遠期改進：

1.做好分庫分表，減少單錶資料量

2.做好資料庫的冷備，縮短以後資料的恢復時間

記錄一次事故 idea，sbt，scala

沒事千萬不要點idea的update啊，就算它自己彈出來的也不要管哦。我們自己的ide在使用過程中總會有各種settting的配置，更新之後這些都沒有了，而且自己本地安裝的外掛程式也就都沒有了，所以更新一定要謹慎。這裡記錄下這次更新，並把更新之後對sbt的配置更改做一次記錄，下次再出現問題就不用去網...

記一次dirty ratio引起的線上事故

磁碟 75 最終累計到100 load1 遠遠 8 cpu mem 85 kernel報錯如下 預設情況下，linux會最多使用40 的可用記憶體作為檔案系統快取。當超過這個閾值後，檔案系統會把將快取中的記憶體全部寫入磁碟，導致後續的io請求都是同步的。將快取寫入磁碟時，有乙個預設120秒的超時時間...

一次線上oom問題記錄

某天早上發現服務無法正常訪問，於是展開問題排查。1。首先檢視日誌，發現有oom日誌存在。這時候看到oom，犯了想當然的錯誤，認為是記憶體不足，堆記憶體空間已經用完。於是檢視 發現某個模組中有如下 誰寫的，站出來，我保證不打你。當時盲目的認為就是使用這個執行緒池的問題 關於此執行緒池的弊端不再贅述 於...