MySQL 死鎖與日誌二三事
阿新 • • 發佈:2017-07-29
mysql索引 open 靜態變量 ... 硬盤 永久 state stack 應該
最近線上 MySQL 接連發生了幾起數據異常,都是在淩晨爆發,由於業務場景屬於典型的數據倉庫型應用,白天壓力較小無法復現。甚至有些異常還比較詭異,最後 root cause 分析頗費周折。那實際業務當中咱們如何能快速的定位線上 MySQL 問題,修復異常呢?下文我會根據兩個實際 case,分享下相關的經驗與方法。
1、Case1:部分數據更新失敗
某天渠道同學反饋某報表極個別渠道數據為 0,大部分渠道數據正常。這個數據是由一個統計程序每天淩晨例行更新的,按理來說,要麽全部正常,要麽全部失敗,那會是什麽原因導致極個別數據異常呢?
首先我們能想到的自然是根據統計任務日誌來看了,但是看了統計程序打印的日誌沒有發現諸如 SQL update 失敗的異常描述,那當時的數據庫究竟發生了什麽呢?在查看 MySQL-server 日誌之前,習慣性的看了下數據庫狀態:
SHOW ENGINE INNODB STATUS\G
恰好看到了淩晨這個 update 發生了死鎖:
------------------------
LATEST DETECTED DEADLOCK
------------------------
2017-07-17 04:09:01 0x7f6de03c8700
*** (1) TRANSACTION:
TRANSACTION 215208479, ACTIVE 0 sec fetching rows
mysql tables in use 3, locked 3
LOCK WAIT 5 lock struct(s), heap size 1136, 3 row lock(s)
MySQL thread id 27844824, OS thread handle 140092183037696, query id 412503674 10.126.95.84 zeye Searching rows for update
update t_channel_final_datas set nr_register=133,nr_add_goods=29,nr_order_normal=11,nr_pay_normal=8,nr_order_special=0,nr_pay_special=0,n_add_user_num=16 where count_date=‘2017-07-16‘ and channel_id=‘16‘ and channel_type=‘10‘ and terminal=‘26‘
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 464 page no 5459 n bits 392 index index_countdate_type_terminal of table `db_zz_flow`.`t_channel_final_datas` trx id 215208479 lock_mode X locks rec but not gap waiting
Record lock, heap no 304 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 10; hex 323031372d30372d3136; asc 2017-07-16;;
1: len 1; hex 30; asc 0;;
2: len 4; hex 80000010; asc ;;
3: len 4; hex 8009055e; asc ^;;
*** (2) TRANSACTION:
TRANSACTION 215208474, ACTIVE 0 sec fetching rows
mysql tables in use 3, locked 3
6 lock struct(s), heap size 1136, 7 row lock(s)
MySQL thread id 27844825, OS thread handle 140109890225920, query id 412503669 10.135.6.41 zeye Searching rows for update
update t_channel_final_datas set nr_register=24,nr_add_goods=32,nr_order_normal=0,nr_pay_normal=0,nr_order_special=0,nr_pay_special=0,n_add_user_num=11 where count_date=‘2017-07-16‘ and channel_id=‘114‘ and channel_type=‘10‘ and terminal=‘116‘
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 464 page no 5459 n bits 392 index index_countdate_type_terminal of table `db_zz_flow`.`t_channel_final_datas` trx id 215208474 lock_mode X locks rec but not gap
Record lock, heap no 304 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 10; hex 323031372d30372d3136; asc 2017-07-16;;
1: len 1; hex 30; asc 0;;
2: len 4; hex 80000010; asc ;;
3: len 4; hex 8009055e; asc ^;;
...
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 464 page no 4743 n bits 264 index PRIMARY of table `db_zz_flow`.`t_channel_final_datas` trx id 215208474 lock_mode X locks rec but not gap waiting
Record lock, heap no 168 PHYSICAL RECORD: n_fields 32; compact format; info bits 0
0: len 4; hex 80090569; asc i;;
1: len 6; hex 00000cd3b9d0; asc ;;
...
*** WE ROLL BACK TRANSACTION (1)