突然有大量業務人員反饋，原有功能不好用。
1. 檢視資料狀態
馬上查詢資料庫查詢發現該資料valid欄位狀態不正確，所以不能進行正常功能的操作。
2. 修復資料減少影響範圍降低損失：
由於不是我負責的業務，所以馬上檢視**邏輯。找到補救狀態而且不影響後續流程的方法，並且確定查詢問題的日誌都齊全不用保留現場，馬上進行操作補救。
上一步是為了臨時解決問題降低損失，接下來就要查詢問題根源，徹底解決問題。
1). 擼**查日誌
檢視服務日誌，發現日誌表明資料庫更新valid欄位時成功了，而且後續也沒有修改valid欄位的操作。但是現在查卻不是當時設定的狀態。經過仔細的日誌查詢之後發現，對於這一條資料的更新只有一條兩分鐘之後的臨近其他操作。馬上找到這塊邏輯**，一段不可描述的**出現在眼前：
這麼寫不會挨打嗎？我解釋一下，第一行從資料庫查詢而且是從庫，第
二、三行copy一下修改了乙個值，第四行整體寫回主庫。因為是整體寫回所以如果在這之間如果valid值被修改是會被覆蓋回去的。這**一看就特麼有問題，哪怕都走主庫都有問題。更何況這是主從分離的。
但是根據日誌分析，上一次的更新是兩分鐘之前的，第一感覺不會這麼大的延遲啊。但是日誌也沒有其他的更新了，不能排除有其他服務更新這條資料。
2). 擼binlog
3). 擼dba
dba問了一下這麼大的延遲什麼情況？dba說今天下午有個bug造成從庫併發鎖等待導致延遲超級超級大。。。
**有問題改**！寫**要多考慮併發情況。
mysql主從同步延遲問題
mysql配置讀寫分離後，master負責所有的寫操作，而從伺服器負責一切的讀操作。其實在資料庫中使用的最多的操作就是讀操作，一般而言，資料庫會有較大可能成為整個系統的瓶頸。導致資料庫主從同步延遲較大的問題一般有以下幾種。1 從伺服器配置較低，只需要公升級從伺服器的配置即可 2 主庫的qps過高導致...
100 解決Mysql主從同步延遲問題
強制讀主過於粗暴，畢竟只有少量寫請求，很短時間，可能讀取到髒資料。有沒有可能實現，只有這一段時間，可能讀到從庫髒資料的讀請求讀主，平時讀從呢？可以利用乙個快取記錄必須讀主的資料。如上圖，當寫請求發生時 1 寫主庫 2 將哪個庫，哪個表，哪個主鍵三個資訊拼裝乙個key設定到cache裡，這條記錄的超時...
MySQL主從延遲分析
主從常見架構 一主多從 級聯複製 多主一從，主主複製。主從複製原理 對於主從來說，通常的操作是主庫用來寫入資料，從庫用來讀取資料。這樣的好處是通過將讀寫壓力分散開，避免了所有的請求都打在主庫上。同時通過從庫進行水平擴充套件使系統的伸縮性及負載能力也得到了很大的提公升。但是問題就來了，讀從庫時的資料要...