update更新"未成功"？
- 前言
- 問題場景
- MySQL出現“寫了binlog但并沒有寫redo-log“
  - 簡單看下兩階段提交的流程
  - 兩階段寫日志的意義？
- 排查陷入僵局
- 排查binlog
  - 排查這段時間內的所有和這個id有關的binlog記錄
- 總結

update更新"未成功"？

前言

筆者最近解決了一個非常曲折的問題，就是業務反應有一條資料進行update并且成功后，查詢依然是舊資料，于是開始一路排查，最后才完美解釋了所有的現象，在這里將整個程序寫成文章記錄下來，希望能夠對讀者有所幫助，(篇幅可能會有點長,耐心看完,絕對物有所值~)

問題場景

業務小明：有一筆訂單更新，更新資料回傳成功，但是資料庫里還是舊的資料，

看了這組資料后，百思不得其解：”不但修改的資料沒有生效，uptime也不一樣了“，于是登錄資料庫進行查詢，結果的確是小明同志描述的那樣，怎么辦呢？

翻了一下關于這條資料的binlog記錄的陳述句確是就是進行了更新，那么問題來了，這不就意味著：

? 寫了binlog但并沒有進行redo-log的更新，這不就資料不一致了啊？

MySQL出現“寫了binlog但并沒有寫redo-log“

中所周知MySQL具有WAL機制（先寫日志，再寫磁盤），我們要搞清楚會不會出現“寫了binlog但并沒有寫redo-log“的情況，就需要研究這個WAL機制的二段提交特性，

在說兩階段提交事物之前，我們先來說說事務，

簡單看下兩階段提交的流程

兩階段提交的時序圖：

粗略觀察一下上圖，MySQL想要執行事務的時候會分成兩個階段

第一階段（prepare階段）：寫rodo-log 并將其標記為prepare狀態，

緊接著寫binlog

第二階段（commit階段）：寫bin-log 并將其標記為commit狀態，

兩階段寫日志的意義？

你有沒有想過這樣一件事，binlog默認都是不開啟的！

也就是說，如果你根本不需要binlog帶給你的特性，那你根本就用不著讓MySQL寫binlog，也用不著什么兩階段提交，

只用一個redolog就夠了，無論你的資料庫如何crash，redolog中記錄的內容總能讓你MySQL記憶體中的資料恢復成crash之前的狀態，

所以說，兩階段提交的主要用意是：為了保證redolog和binlog資料的安全一致性（劃重點！！!拐杖敲黑板3次），只有在這兩個日志檔案邏輯上高度一致了，你才能放心的使用redolog幫你將資料庫中的狀態恢復成crash之前的狀態，使用binlog實作資料備份、恢復、以及主從復制，而兩階段提交的機制可以保證這兩個日志檔案的邏輯是高度一致的，沒有錯誤、沒有沖突，

排查陷入僵局

? 看到這里我們就發現兩階段提交保證了redolog和binlog資料的安全一致性，binlog里進行commit，redolog里一定是成功的也就是說：

? 根本不可能出現寫了binlog但并沒有寫redo-log的情況，完全不會出現小明描述的那樣的問題，

經過反復思考，真実(しんじつ)はいつもひとつ平假名:しんじつはいつもひとつ（真相只有一個）

那就是描述資訊里有遺漏，在更新后和查詢前必定有一個事務對這個記錄進行了操作，

排查binlog

1.排查這段時間內的所有和這個id有關的binlog，并提取出相關記錄

2.找出更新后和查詢前的那個事務的binlog

排查這段時間內的所有和這個id有關的binlog記錄

如何出排查這段時間內的所有和這個id有關的binlog記錄呢，這么多的binlog，那只能寫個腳本就行批處理了，

file_list=$(ls mysql-bin.00*)
for i in file_list
do	
    count=`mysqlbinlog -vv -d t100w.t_250w $i |grep -c "{主鍵id}"`
	[ $count -gt 0 ] && (echo $i $count)
done

## 代碼解釋：
# mysqlbinlog -d t100w.t_250w 只查看t100w庫t_250w表的binlog
# grep -c  統計檔案中搜索關鍵字的個數（等價于 select count(*) from table where id > ?）
# 通過ls獲取到所有mysql-bin，通過for回圈找到搜索關鍵字的個數大于0的檔案,并列印檔案名和統計個數

然后使用less命令，搜索主鍵id，

mysqlbinlog -vv -d t100w.t_250w mysql-bin.009820|less
# less內
# /主鍵id

最終找到了那條記錄，真相大白：

總結

有時候問題并沒有那么復雜，并不是MySQL底層除了問題，而是“小明”在提供資訊的時候不一定能把問題準確的描述清楚，導致我們的一些誤判，在處理問題上應該先從距離問題最近的角度出發，感謝大家看完一名菜雞DBA的文章，我們下個文章再見！

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/279512.html

標籤：MySQL

上一篇：大神們，幫忙修改個SQLSERVER INSERT觸發器，專門修正誤差率的

下一篇：SQL練習——2020滴滴面試題