一次線上mysql死鎖分析
一、現象
發運車次呼叫發車介面時發生異常,後臺丟擲資料庫死鎖日誌。
二、原因分析
通過日誌可以看出事務T1等待 heap no 8的行鎖 (X locks 排他鎖)
事務T2持有heap no 8的行鎖,等待heap no 7的行鎖
兩個更新運單sql發生死鎖。
三、程式碼追蹤
發車介面:/ltl/loadShiftOrg/send
更新運單狀態通過迴圈遍歷進行操作,比較耗時。
其他介面更新運單導致發生死鎖
在發車介面之前還呼叫了另外一個介面
/ltl/loadShift/saveOrUpdateShift
該介面中有個批量裝車的操作:
該介面中進行了運單更新。
四、解決方案
1>設定mysql 鎖超時引數 innodb_lock_wait_timeout 現在預設50(s)
2>優化程式碼批量更新運單狀態:
3>前端呼叫/saveOrUpdateShift後等待返回結果之後再呼叫/send介面
五、經驗
- 資料庫的批量操作儘量通過sql來執行。
- Mysql部分引數進行調優。
相關推薦
一次線上mysql死鎖分析
一、現象 發運車次呼叫發車介面時發生異常,後臺丟擲資料庫死鎖日誌。 二、原因分析 通過日誌可以看出事務T1等待 heap no 8的行鎖 (X locks 排他鎖) 事務T2持有heap no 8的行鎖,等待heap no 7的行鎖 兩個更新運
記一次線上MySQL數據庫死鎖問題
重復 成功 中一 主鍵 adl 一次 his TE BE 最近線上項目報了一個MySQL死鎖(DealLock)錯誤,雖說對業務上是沒有什麽影響的,由於自己對數據庫鎖這塊了解不是很多,之前也沒怎麽的在線上碰到過。這次剛好遇到了,便在此記錄一下。 出現
MySQL死鎖分析一例
Tomcat日誌報死鎖錯誤,show innodb status獲取死鎖資訊: ------------------------ LATEST DETECTED DEADLOCK ------------------------ 181107 9:30:46 *** (1) TRANSACTION:
一次查詢sqlserver死鎖的經歷
查詢bug是程式設計師的家常便飯,我身邊的人喜歡讓使用者來重現問題。當然他們也會從正式伺服器上下載錯誤log,然後嘗試分析log,不過當錯誤不是那種不經思考就可識別的情況,他們就會將問題推向使用者,甚至怪罪程式依賴的平臺。他們常用的藉口就是“這個問題很難重現,需要持續監控
MySQL死鎖分析及解決的方法--例子
http://soft.chinabyte.com/database/385/12532885.shtml 5、死鎖舉例分析 在MySQL中,行級鎖並不是直接鎖記錄,而是鎖索引。索引分為主鍵索引和非主鍵索引兩種,如果一條sql語句操作了主鍵索引,MySQL就會鎖
一個最不可思議的MySQL死鎖分析
死鎖問題背景 做MySQL程式碼的深入分析也有些年頭了,再加上自己10年左右的資料庫核心研發經驗,自認為對於MySQL/InnoDB的加鎖實現瞭如指掌,正因如此,前段時間,還專門寫了一篇洋洋灑灑的文章,專門分析MySQL的加鎖實現細節:《MySQL加鎖處理分析》
記一次線上mysql主從架構異常的恢復經歷
fault ase 主從數據庫 sta start 1-1 href show color 前提:之前一位同事負責的一位客戶,因後期轉到devops小組。所以將此用戶交接給我,在後期發現有一套數據庫主從環境,從庫已經無法正常使用。查看slave 狀態為: 其中:Master
原創 記錄一次線上Mysql慢查詢問題排查過程
背景 前段時間收到運維反饋,線上Mysql資料庫凌晨時候出現慢查詢的報警,並把原始sql發了過來: --去除了業務含義的sql update test_user set a=1 where id=1; 表資料量200W左右,不是很大,而且是根據主鍵更新。 問題排查 排查Mysql資料庫 我看到sql後第一
一次 MySQL 線上死鎖分析實戰
> 關鍵詞:MySQL Index Merge ## 前言 MySQL 的鎖機制相信大家在學習 MySQL 的時候都有簡單的瞭解過,那既然有鎖就必定繞不開死鎖這個問題。其實 MySQL 在大部分場景下是不會存在死鎖問題的(比如併發量不高,SQL 寫得不至於太拉胯的情況),但是在高併發的業務場景下,一
Mysql死鎖如何排查:insert on duplicate死鎖一次排查分析過程
前言 遇到Mysql死鎖問題,我們應該怎麼排查分析呢?之前線上出現一個insert on duplicate死鎖問題,本文將基於這個死鎖問題,分享排查分析過程,希望對大家有幫助。 死鎖案發還原 表結構: CREATE TABLE `song_rank` ( `id` int(11) NOT NULL AU
一次Mysql死鎖排查過程的全紀錄
前言之前接觸到的資料庫死鎖,都是批量更新時加鎖順序不一致而導致的死鎖,但是上週卻遇到了一個很難理解的死鎖。藉著這個機會又重新學習了一下mysql的死鎖知識以及常見的死鎖場景。在多方調研以及和同事們的討論下終於發現了這個死鎖問題的成因,收穫頗多。雖然是後端程式設計師,我們不需要
記錄一次Mysql死鎖排查過程
知識 body ext 兩個 next ron 討論 不一致 test 背景 以前接觸到的數據庫死鎖,都是批量更新時加鎖順序不一致而導致的死鎖,但是上周卻遇到了一個很難理解的死鎖。借著這個機會又重新學習了一下mysql的死鎖知識以及常見的死鎖場景。在多方調研以及和同事們的
一次MySQL死鎖的排查記錄
前幾天線上收到一條告警郵件,生產環境MySQL操作發生了死鎖,郵件告警的提煉出來的SQL大致如下。 ```SQL update pe_order_product_info_test set end_time = '2021-04-30 23:59:59' where or
mysql 死鎖簡單分析
-- hand ODB star 資源 無法 作用 dex size mysql都有什麽鎖 MySQL有三種鎖的級別:頁級、表級、行級,內存級(latch)。 表級鎖:開銷小,加鎖快;不會出現死鎖;鎖定粒度大,發生鎖沖突的概率最高,並發度最低。 行級鎖:開銷大,加鎖慢;會
通過 jstack 與 jmap 分析一次線上故障
一、發現問題 下面是線上機器的cpu使用率,可以看到從4月8日開始,隨著時間cpu使用率在逐步增高,最終使用率達到100%導致線上服務不可用,後面重啟了機器後恢復。 二、排查思路 簡單分析下可能出問題的地方,分為5個方向: 系統本身程式碼問題 內部下游系統的問題導致的雪
總結線上遇到的MySQL死鎖問題
線上遇到了MySQL死鎖的相關問題,需要檢視MySQL出現的Deadlock日誌,可以通過執行: show engine innodb status 來檢視innodb型別資料庫的狀態,查詢laster detected deadlock部分,可以看到最近造成死鎖的兩條sql ----
MySQL死鎖問題分析
圖4 聚簇索引和二級索引 下面分析下索引和鎖的關係。 1)delete from msg where id=2; 由於id是主
記一次生產DB2資料庫鎖超時問題的分析與排查
作者介紹 侯君,證通股份有限公司DBA,主要負責DB2、MySQL、Couchbase運維,以及自動化運維平臺開發,Python愛好者。 前言 DB2的鎖管理機制一直為DB2應用開發人員和DBA所詬病。對其鎖機制不理解的直接後果就是導致鎖超時和死鎖的發生。所以監控並分析鎖超時和死鎖,應是每個DB2
MySQL死鎖問題例項分析及解決方法(主要是SQL語句可能會產生的問題)
from: http://database.51cto.com/art/201108/286325.htm MySQL死鎖問題的相關知識是本文我們主要要介紹的內容,接下來我們就來一一介紹這部分內容,希望能夠對您有所幫助。 1、MySQL常用儲存引擎的鎖機制 MyISAM
MySql 死鎖時的一種解決辦法
之前也遇到一次,今天又遇到了這個問題,所以這次必須解決,網上找到這篇文章幫了大忙,方便以後複習。這篇文章的解決辦法對於我的情況是有效的。 我的具體情況是:使用RobotFramework測試時,本來可以通過的一個case報錯了,報錯為:InternalError: (1