-------------------------------------------------------------------------------------------------短文---------------------------------------------------------------------------------------------------------------
場景:
MySQL-5.7.17, 主從架構, 業務讀寫分離, 只讀從庫的SQL執行緒卡在某一個事務兩個多小時沒有動過, IO執行緒正常;

結論:
給某個表加上了索引, 同步開始追趕 _(:з」∠)_
叮囑程式要養成加主鍵的好習慣.....ㄟ( ▔, ▔ )ㄏ

分析:
第一反應是bug?? hang住了? 在delete幾千萬的表?? _(:з」∠)_;

事務提交策略是2,0, 沒有開啟log_slave_update, 按道理來說, 純粹的執行事務, 不應該會卡住, 後臺的一些執行緒也是suspending, 不是running, 好像也不是執行緒之間的問題, 看看relaylog裡面是什麼語句...

卡住的地方, 可以看到是929064394事務

把relaylog轉義一下, 找一下這個事務, 發現確實是很多的delete語句(內容已處理)

大概統計了一下, 刪除了有15W左右的資料, 然後看了一下兩個多小時的時間, 同步進度如何...

只從速度上看, 還得卡兩個多小時, 而且之後還有類似的語句, 真要完全追上, 估計.....

於是看了眼這個tmp_log表的結構

點選(此處)摺疊或開啟

CREATE TABLE `tmp_log` (
`s_id` int DEFAULT NULL,
`d_id` int DEFAULT NULL
) ENGINE=InnoDB

木有主鍵..... _(:з」∠)_

同步和主鍵有什麼關係?
MySQL同步的時候, 會去利用主鍵來搜尋需要修改的行(或者是一些二級索引);

PS: 具體的資料可以參考slave_rows_search_algorithms的官方解釋, 預設的設定下, 如果沒主鍵也沒有二級索引(where條件可用), 那麼就會用全表掃描來搜尋資料;
摘抄部分

點選(此處)摺疊或開啟

? The default value is TABLE_SCAN,INDEX_SCAN, which means that all searches that can use indexes do use them, and searches without any indexes use table scans.
? To use hashing for any searches that do not use a primary or unique key, set this option to INDEX_SCAN,HASH_SCAN. Specifying INDEX_SCAN,TABLE_SCAN,HASH_SCAN has the same effect as specifying INDEX_SCAN,HASH_SCAN.
? To force hashing for all searches, set this option to TABLE_SCAN,HASH_SCAN.

PPS: 開啟HASH_SCAN可能對這個場景有效;
PPPS: HASH_SCAN預設沒有開, 並且開啟HASH_SCAN在某些情況下會遇到bug, 升級到>=5.7.20的版本之後再考慮開HASH_SCAN;

不打算去定位"為什麼從庫TABLE_SCAN這麼慢?"了, 把表加上索引吧...

"想辦法"停掉了同步, 加上索引之後, 同步恢復正常了;

MySQL案例-replication"卡死"

相關文章