乙個**的專案，開始的配置是在阿里雲上買了一台資料庫rds（8核16g)，一台雲伺服器ecs(8核16g) 執行了一段時間之後，使用者量上公升很快，資料庫的負荷經常超過80%，早忙時階段（上午9點到11點），晚忙時階段（晚上9點到11點） 負荷經常滿負荷100%的再跑，除了做sql的優化之外，最快的解決方案就是實施資料庫的主從，增加唯讀節點，將平台的讀取操作分流到唯讀資料庫。
方案確定後，在阿里雲上購買唯讀從庫，這個過程大約需要半個小時，阿里雲需要將主庫資料複製到唯讀從庫中， 唯讀從庫執行成功之後，還需要購買阿里雲的資料庫**，資料庫**負責把資料庫訪問的請求，進行讀寫分離，將讀取的流量全部分到唯讀庫中，也可以按照權重，將讀取流量按比例分流到從庫和主庫，當時配置的策略：所有讀取操作全部分流到從庫， 寫操作全部在主庫。
整個資料庫主從架構部署完畢之後， 服務端這邊的程式的改造就很簡單，只需要將資料庫連線的位址，更換成書庫**的位址，完成資料庫連線位址的切換之後，整個過程非常順暢，主庫的cpu負荷一下子就降到40%左右，從庫的負荷在50%，觀察了一段時間，業務執行正常，當時以為一切就完美結束。
資料庫端沒有問題，就開始檢查服務端程式，服務端程式是使用php編寫，再檢查執行日誌發現，有報錯現象：
通過日誌發現，有表未發現錯誤，而且這張是一張臨時表， 一般mysql資料庫的臨時表有兩種，一種是外部主動建立臨時，也就是我們寫的程式裡主動建立臨時表，用於資料的處理，另外就是mysql自己內部建立臨時表，一般出現group by這樣的語句的時候，mysql系統自動建立內部的臨時表。
通過日誌發現，這個臨時表是主動建立的，詢問之後，確實是乙個工程師使用了臨時表，進行資料的處理。 那問題來了：為啥之前沒有問題， 實施了讀寫分離之後，就出現了問題。 這個就是我們今天講的重點：這種在程式裡建立的臨時表，不是寫在磁碟檔案裡的，是直接寫在記憶體裡，一旦程式鏈結斷開後，該臨時表就消失了。 那回到我們問題的焦點上來：之前只有乙個資料庫，所有讀寫全部在乙個庫上，所以程式執行不會出現問題。 當進行讀寫分離之後， 臨時表是建立在主庫的記憶體裡，而且這種臨時表是無法進行主從同步的，當程式讀取資料時，去從庫肯定無法讀取到資料，會提示該臨時表不存在的錯誤。
一次斷電引發的svn資料庫故障
昨天辦公室停電了。然後今天更新svn資料庫時出現乙個不能讀取檔案 end of file found的錯誤，具體如下圖 上網搜尋了一下，大致明白了錯誤原因，應該就是在提交原始碼時遭遇斷電，導致提交的原始碼版本號沒有寫入版本檔案。具體的svn版本號儲存在 svn資料庫目錄下的 db current 我...
一次線上故障引發的警示
這次引發的線上故障和我有直接關係，現分析一下這次故障產生的原因和經驗教訓，還請大家引以為戒。原因分析 1 在 公升級包開發過程中，編寫偽登陸介面測試用例時走讀介面 發現對介面引數控制不嚴格 判斷引數是否為null 對其重構為更嚴格引數控制 判斷null或空字串 但未考慮到 中的潛規則 呼叫方就是傳遞...
一次執行緒引發的髒資料
專案新增新功能，功能做完測試階段在資料庫出現髒資料，正常的資料有兩種 但是不定時會出現 這樣的資料，排查思路是這樣的 一 問題分析。髒資料應該不是憑空出現的，按照資料內容情況比較像兩種型別的資料拼接而成。而chargedate是date型別的資料轉換而成所以問題應該出現在date型別處理這方面，查詢...