MySQL從庫卡主了--讀寫分離也不能亂讀

不少使用資料庫的公司，資料庫都建立主從。無論Oracle、MySQL還是PostgreSQL都會有這類應用。而TiDB這種分散式資料本身是一套高可用。當然我剛才提到的Oracle、MySQL還是PostgreSQL也早就有了自己的分散式。我們今天還是說主從的這種架構。一般主從可以起到硬體故障的災備，但是現在的硬體情況，很少硬體損壞。大家用從庫做讀寫分離或者說分析的也很多。（如果說現在誰家的硬體天天壞，天天進行災備切換實操的）

     今天說一個故事，我的一個學員問我她們遇到的問題：上來給我一張圖。我看到這個描述第一次見。只能說明踩坑還不夠。然後看到她圖中主從差了28000多秒。我說這種情況基本上指望同步恢復不現實了。（以我以前經驗這話還能追回來的機率不大，不過最後結果還是反轉的）

然後她不經意間截圖了這個。我看到了“ invalidating query cache entries ”那麼說明從庫在刷快取的時候卡主了。我開始以為是insert沒提交。不過實際情況是她一主三從的資料庫上，一主和兩個從上都是好的，已經插入了。那麼就排除了各種我能想到的問題。只有一種可能了，有人在這個庫上執行大查詢，導致記憶體競爭，卡主了。事務提交不下去。

     隨機讓她檢查這個從庫上有沒有大查詢。一查果然有。 那麼結果就是殺掉這幾個大查詢，或者把從庫重啟一下。最終採用了kill會話的操作，解決了。那幾個殺掉的我這裡就不貼了。大致是select distinct x,y,z.......... from t     重點是沒有where條件。而且是不止一個會話這樣執行，然後就沒有然後了。對於這樣全表遍歷且排序的併發執行，我見過幾次這種都造成故障了（當時是主庫）。這個由於是人為查詢的從庫，估計現場沒有造成影響，但是確實是問題。

     主從產生延遲的幾種可能性

1、主大事務從在等
2、從序列執行忙不過來
3、從執行的事務阻塞了主的同步事務

    有時候不能因為是從庫，就可以無節操的查詢，比如全量運算元據，也是有可能把從庫搞癱瘓的。