MySQL पर लॉक वेट टाइमआउट को कैसे डीबग करें?

269

अपने उत्पादन त्रुटि लॉग में मैं कभी-कभी देखता हूं:

SQLSTATE [HY000]: सामान्य त्रुटि: 1205 लॉक प्रतीक्षा समय समाप्त हो गया; लेनदेन को पुनः आरंभ करने का प्रयास करें

मुझे पता है कि कौन सी क्वेरी उस पल में डेटाबेस तक पहुँचने की कोशिश कर रही है, लेकिन क्या यह पता लगाने का एक तरीका है कि उस सटीक क्षण में किस क्वेरी में लॉक था?

mysql  debugging  transactions  innodb  acid 
— मैट मैककॉर्मिक
स्रोत
1
मैं भारी सुझाव है कि हर कोई Eirik एक शॉट जवाब देने के लिए
— kommradHomer 7
— मैक्स अलेक्जेंडर हन्ना

जवाबों:

261

क्या यह दूर देता है शब्द लेनदेन है । इस कथन से स्पष्ट होता है कि क्वेरी एक या एक से अधिक InnoDB तालिकाओं में कम से कम एक पंक्ति को बदलने का प्रयास कर रही थी।

चूंकि आप क्वेरी जानते हैं, इसलिए एक्सेस की जा रही सभी तालिकाएँ अपराधी होने के लिए उम्मीदवार हैं।

वहां से, आपको चलाने में सक्षम होना चाहिए SHOW ENGINE INNODB STATUS\G

आपको प्रभावित तालिका देखने में सक्षम होना चाहिए

आपको सभी प्रकार की अतिरिक्त लॉकिंग और म्यूटेक्स जानकारी मिलती है।

यहाँ मेरे एक ग्राहक का एक नमूना है:

mysql> show engine innodb status\G
*************************** 1. row ***************************
  Type: InnoDB
  Name:
Status:
=====================================
110514 19:44:14 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 4 seconds
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 9014315, signal count 7805377
Mutex spin waits 0, rounds 11487096053, OS waits 7756855
RW-shared spins 722142, OS waits 211221; RW-excl spins 787046, OS waits 39353
------------------------
LATEST FOREIGN KEY ERROR
------------------------
110507 21:41:35 Transaction:
TRANSACTION 0 606162814, ACTIVE 0 sec, process no 29956, OS thread id 1223895360 updating or deleting, thread declared inside InnoDB 499
mysql tables in use 1, locked 1
14 lock struct(s), heap size 3024, 8 row lock(s), undo log entries 1
MySQL thread id 3686635, query id 124164167 10.64.89.145 viget updating
DELETE FROM file WHERE file_id in ('6dbafa39-7f00-0001-51f2-412a450be5cc' )
Foreign key constraint fails for table `backoffice`.`attachment`:
,
  CONSTRAINT `attachment_ibfk_2` FOREIGN KEY (`file_id`) REFERENCES `file` (`file_id`)
Trying to delete or update in parent table, in index `PRIMARY` tuple:
DATA TUPLE: 17 fields;
 0: len 36; hex 36646261666133392d376630302d303030312d353166322d343132613435306265356363; asc 6dbafa39-7f00-0001-51f2-412a450be5cc;; 1: len 6; hex 000024214f7e; asc   $!O~;; 2: len 7; hex 000000400217bc; asc    @   ;; 3: len 2; hex 03e9; asc   ;; 4: len 2; hex 03e8; asc   ;; 5: len 36; hex 65666635323863622d376630302d303030312d336632662d353239626433653361333032; asc eff528cb-7f00-0001-3f2f-529bd3e3a302;; 6: len 40; hex 36646234376337652d376630302d303030312d353166322d3431326132346664656366352e6d7033; asc 6db47c7e-7f00-0001-51f2-412a24fdecf5.mp3;; 7: len 21; hex 416e67656c73204e6f7720436f6e666572656e6365; asc Angels Now Conference;; 8: len 34; hex 416e67656c73204e6f7720436f6e666572656e6365204a756c7920392c2032303131; asc Angels Now Conference July 9, 2011;; 9: len 1; hex 80; asc  ;; 10: len 8; hex 8000124a5262bdf4; asc    JRb  ;; 11: len 8; hex 8000124a57669dc3; asc    JWf  ;; 12: SQL NULL; 13: len 5; hex 8000012200; asc    " ;; 14: len 1; hex 80; asc  ;; 15: len 2; hex 83e8; asc   ;; 16: len 4; hex 8000000a; asc     ;;

But in child table `backoffice`.`attachment`, in index `PRIMARY`, there is a record:
PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 30; hex 36646261666133392d376630302d303030312d353166322d343132613435; asc 6dbafa39-7f00-0001-51f2-412a45;...(truncated); 1: len 30; hex 38666164663561652d376630302d303030312d326436612d636164326361; asc 8fadf5ae-7f00-0001-2d6a-cad2ca;...(truncated); 2: len 6; hex 00002297b3ff; asc   "   ;; 3: len 7; hex 80000040070110; asc    @   ;; 4: len 2; hex 0000; asc   ;; 5: len 30; hex 416e67656c73204e6f7720436f6e666572656e636520446f63756d656e74; asc Angels Now Conference Document;;

------------
TRANSACTIONS
------------
Trx id counter 0 620783814
Purge done for trx's n:o < 0 620783800 undo n:o < 0 0
History list length 35
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 0, not started, process no 29956, OS thread id 1192212800
MySQL thread id 5341758, query id 189708501 127.0.0.1 lwdba
show innodb status
---TRANSACTION 0 620783788, not started, process no 29956, OS thread id 1196472640
MySQL thread id 5341773, query id 189708353 10.64.89.143 viget
---TRANSACTION 0 0, not started, process no 29956, OS thread id 1223895360
MySQL thread id 5341667, query id 189706152 10.64.89.145 viget
---TRANSACTION 0 0, not started, process no 29956, OS thread id 1227888960
MySQL thread id 5341556, query id 189699857 172.16.135.63 lwdba
---TRANSACTION 0 620781112, not started, process no 29956, OS thread id 1222297920
MySQL thread id 5341511, query id 189696265 10.64.89.143 viget
---TRANSACTION 0 620783736, not started, process no 29956, OS thread id 1229752640
MySQL thread id 5339005, query id 189707998 10.64.89.144 viget
---TRANSACTION 0 620783785, not started, process no 29956, OS thread id 1198602560
MySQL thread id 5337583, query id 189708349 10.64.89.145 viget
---TRANSACTION 0 620783469, not started, process no 29956, OS thread id 1224161600
MySQL thread id 5333500, query id 189708478 10.64.89.144 viget
---TRANSACTION 0 620781240, not started, process no 29956, OS thread id 1198336320
MySQL thread id 5324256, query id 189708493 10.64.89.145 viget
---TRANSACTION 0 617458223, not started, process no 29956, OS thread id 1195141440
MySQL thread id 736, query id 175038790 Has read all relay log; waiting for the slave I/O thread to update it
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
519878 OS file reads, 18962880 OS file writes, 13349046 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 6.25 writes/s, 4.50 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 1190, seg size 1192,
174800 inserts, 174800 merged recs, 54439 merges
Hash table size 35401603, node heap has 35160 buffer(s)
0.50 hash searches/s, 11.75 non-hash searches/s
---
LOG
---
Log sequence number 28 1235093534
Log flushed up to   28 1235093534
Last checkpoint at  28 1235091275
0 pending log writes, 0 pending chkp writes
12262564 log i/o's done, 3.25 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 18909316674; in additional pool allocated 1048576
Dictionary memory allocated 2019632
Buffer pool size   1048576
Free buffers       175763
Database pages     837653
Modified db pages  6
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 770138, created 108485, written 7795318
0.00 reads/s, 0.00 creates/s, 4.25 writes/s
Buffer pool hit rate 1000 / 1000
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 29956, id 1185823040, state: sleeping
Number of rows inserted 6453767, updated 4602534, deleted 3638793, read 388349505551
0.25 inserts/s, 1.25 updates/s, 0.00 deletes/s, 2.75 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

1 row in set, 1 warning (0.00 sec)

आपको InnoDB के लिए innodb_lock_wait_timeout सेट करके लॉक प्रतीक्षा समय मान बढ़ाने पर विचार करना चाहिए , डिफ़ॉल्ट 50 सेकंड है

mysql> show variables like 'innodb_lock_wait_timeout';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 50    |
+--------------------------+-------+
1 row in set (0.01 sec)

आप इसे /etc/my.cnfइस पंक्ति के साथ स्थायी रूप से उच्च मूल्य पर सेट कर सकते हैं

[mysqld]
innodb_lock_wait_timeout=120

और mysql को पुनरारंभ करें। यदि आप इस समय mysql को पुनः आरंभ नहीं कर सकते हैं, तो इसे चलाएं:

SET GLOBAL innodb_lock_wait_timeout = 120;

आप इसे अपने सत्र की अवधि के लिए भी निर्धारित कर सकते हैं

SET innodb_lock_wait_timeout = 120;

आपके प्रश्न के बाद

— RolandoMySQLDBA
स्रोत
5
अंतर्निहित InnoDB के लिए, innodb_lock_wait_timeoutचर केवल सर्वर स्टार्टअप पर सेट किया जा सकता है। InnoDB प्लगइन के लिए, इसे स्टार्टअप पर सेट किया जा सकता है या रनटाइम में बदला जा सकता है, और इसमें वैश्विक और सत्र दोनों मान हैं।
— टिमो हुओविनन
1
हाय @rolandomysqldba, क्या आप मुझे इस पोस्ट पर अपना सुझाव दे सकते हैं: stackoverflow.com/questions/18267565/…
— मनीष सपकाल
2
पहली क्वेरी को चलाने का प्रयास करने पर मुझे यह त्रुटि मिलती है:SQL Error (1064): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\G' at line 1
— Iulian Onofrei
1
@Pacerier हर बार जब mysqld को पुनरारंभ किया जाता है, तो आपको SET GLOBAL innodb_lock_wait_timeout = 120;फिर से दौड़ना पड़ता है। यदि आपके /etc/my.cnfपास विकल्प है, innodb_lock_wait_timeoutतो आपके लिए निर्धारित है। हर किसी को इसे हर किसी के लिए विश्व स्तर पर बदलने का सर्वोच्च विशेषाधिकार नहीं है ( dev.mysql.com/doc/refman/5.6/en/… )
— RolandoMySQLDBA
3
@IulianOnofrei \ G चरित्र MySQL कमांड लाइन की एक विशेष विशेषता है और आउटपुट प्रदर्शित करने के तरीके को बदलता है। अन्य MySQL क्लाइंट के लिए केवल एक नियमित अर्धविराम का उपयोग करें।
— तत्पश्चात
83

जैसा कि किसी ने इस समस्या से संबंधित कई SO थ्रेड्स में से एक में उल्लेख किया है: कभी-कभी जिस प्रक्रिया ने तालिका को लॉक किया है वह प्रक्रियासूची में सोते हुए दिखाई देती है! मैं अपने बालों को तब तक फाड़ रहा था जब तक कि मैंने सभी नींद के धागे नहीं मार दिए जो कि डेटाबेस में खुले थे (कोई भी उस समय सक्रिय नहीं थे)। अंत में टेबल को अनलॉक किया और अपडेट क्वेरी को चलने दें।

टिप्पणीकार ने कहा कि कुछ समय के लिए "कभी-कभी एक MySQL धागा एक मेज को बंद कर देता है, फिर सोता है जबकि यह कुछ गैर-MySQL से संबंधित होने की प्रतीक्षा करता है।"

show engine innodb statusलॉग को फिर से समीक्षा करने के बाद (एक बार जब मैं ग्राहक को लॉक के लिए जिम्मेदार ठहराता हूं), तो मैंने देखा कि प्रश्न में अटका हुआ धागा लेन-देन की सूची में बहुत नीचे सूचीबद्ध था, जो कि सक्रिय प्रश्नों के नीचे था, जो त्रुटि के बारे में थे। जमे हुए ताला के कारण बाहर:

------------------
---TRANSACTION 2744943820, ACTIVE 1154 sec(!!)
2 lock struct(s), heap size 376, 2 row lock(s), undo log entries 1
MySQL thread id 276558, OS thread handle 0x7f93762e7710, query id 59264109 [ip] [database] cleaning up
Trx read view will not see trx with id >= 2744943821, sees < 2744943821

(अनिश्चित अगर "ट्रक्स रीड व्यू" संदेश जमे हुए लॉक से संबंधित है, लेकिन अन्य सक्रिय लेनदेन के विपरीत, यह जारी किए गए क्वेरी के साथ नहीं दिखता है और इसके बजाय लेनदेन "सफाई कर रहा है" का दावा है, अभी तक कई है पंक्ति ताले)

कहानी का नैतिक यह है कि एक लेनदेन सक्रिय हो सकता है, भले ही धागा सो रहा हो।

— एरिक एल।
स्रोत
2
मैं यह नहीं कह सकता कि आपने मेरा जीवन बचाया है, लेकिन आपने मेरे मन को शांति के लिए निश्चित किया है। आपके उत्तर को पढ़ते हुए, मुझे एक डरावना धागा मिला जो 3260 सेकंड के लिए सक्रिय है, और कहीं भी दिखाई नहीं दे रहा है। इसे मारने के बाद, मेरी सभी समस्याएं हल हो गईं!
— कोमराधोमेर
यह मेरी समस्या थी। 20,000 सेकंड के समय के साथ एक नींद का लेन-देन जो देरी से नौकरी को रेल एप्लिकेशन में ठीक से चलाने से रोक रहा था। साभार @Eirik
— bigtex777
किसी भी विचार क्यों एक नींद लेनदेन वैसे भी बंद नहीं मिलता है? जैसे, क्या कोई समयसीमा है जिसे आप निर्धारित कर सकते हैं कि एक लेनदेन समाप्त होना चाहिए?
— patrickdavey
1
अन्य आदेश जो लेनदेन को लॉक करने के लिए आपकी खोज में सहायक हो सकते हैं: show processlist;वर्तमान में निष्पादित होने वाली प्रक्रियाओं की एक विस्तृत सूची दिखाने के लिए, जो अच्छा है क्योंकि यह एक संघनित संस्करण है show engine innodb status\g। इसके अलावा, यदि आपका डीबी अमेज़ॅन आरडीएस उदाहरण पर है, तो आप CALL mysql.rds_kill(<thread_id>);थ्रेड्स को मारने के लिए उपयोग कर सकते हैं । मेरे पास इसकी उच्च अनुमति है, क्योंकि इसने मुझे सादे से अधिक प्रक्रियाओं को मारने की अनुमति दी kill <thread_id>;- ध्यान दें कि इन्हें MySQL CLI
— निकंग
1
किसी के पास इसके लिए एक स्रोत है - हो सकता है कि एक दस्तावेज़ीकरण पृष्ठ जो बताते हैं कि COMMIT चरण से पहले ताले लगाए गए हैं? मुझे इस सटीक मुद्दे को देखने के बावजूद कुछ भी नहीं मिला, और ताले को पकड़े हुए सोने के धागे को मारकर इसे साफ किया गया।
— एरिन शूनओवर
42

MySQL की लोकप्रियता के कारण, कोई आश्चर्य नहीं कि लॉक प्रतीक्षा समय समाप्त हो गया है; लेनदेन के अपवाद को फिर से शुरू करने की कोशिश एसओ पर इतना ध्यान देती है।

आपके पास जितना अधिक विवाद होगा, गतिरोध की संभावना उतनी ही अधिक होगी, जो एक डीबी इंजन समय-सीमा के गतिरोध वाले लेनदेन में से एक को हल करेगा। इसके अलावा, लंबे समय से चल लेनदेन है कि संशोधित किया है (उदाहरण के लिए UPDATEया DELETE) प्रविष्टियां (जो से बचने के गंदे-लिखने की विसंगतियों में बताई गई विधि के ताले लेने की एक बड़ी संख्या उच्च प्रदर्शन जावा हठ पुस्तक) अधिक अन्य लेनदेन के साथ संघर्ष उत्पन्न करने के लिए की संभावना है।

हालांकि InnoDB MVCC, आप अभी भी क्लॉज का उपयोग करके स्पष्ट ताले काFOR UPDATE अनुरोध कर सकते हैं । हालाँकि, अन्य लोकप्रिय DBs (Oracle, MSSQL, PostgreSQL, DB2) के विपरीत, MySQL डिफ़ॉल्ट अलगाव स्तर के रूप में उपयोग करता REPEATABLE_READहै ।

अब, आपके द्वारा अधिग्रहित ताले (या तो पंक्तियों को संशोधित करके या स्पष्ट लॉकिंग का उपयोग करके), वर्तमान में चल रहे लेनदेन की अवधि के लिए आयोजित किए जाते हैं। आप के बीच अंतर का एक अच्छा स्पष्टीकरण चाहते हैं REPEATABLE_READऔर READ COMMITTEDलॉकिंग के संबंध में, कृपया इस लेख को पढ़ने के Percona ।

दोहराए जाने वाले सौदे में, लेन-देन के दौरान अधिग्रहित प्रत्येक ताला लेनदेन की अवधि के लिए आयोजित किया जाता है।

READ COMMITTED में वे ताले जो स्‍कैन से मेल नहीं खाते, स्‍टैटमेंट पूरा होने के बाद जारी किए जाते हैं।

...

इसका मतलब यह है कि पढ़े गए अन्य लेनदेन पंक्तियों को अद्यतन करने के लिए स्वतंत्र हैं, जो अद्यतन किए जाने के बाद (अद्यतन विवरण में) वे अपडेट नहीं कर पाएंगे।

इसलिए: अधिक प्रतिबंधात्मक अलगाव स्तर ( REPEATABLE_READ, SERIALIZABLE) अधिक से अधिक गतिरोध का मौका। यह एक मुद्दा "प्रति से" नहीं है, यह एक व्यापार बंद है।

आप कई HTTP अनुरोधों पर होने वाले तार्किक लेन-देन का उपयोग करते समय बहुत अच्छे परिणाम प्राप्त कर सकते हैं READ_COMMITED, क्योंकि आपको एप्लिकेशन-लेवल लॉस्ट अपडेट रोकथाम की आवश्यकता होती है। आशावादी ताला दृष्टिकोण लक्ष्य अपडेट खो दिया हो सकता है कि भले ही आप का उपयोग SERIALIZABLEअलगाव के स्तर का है, जबकि आप का उपयोग करने की अनुमति देकर ताला विवाद को कम करने READ_COMMITED।

— व्लाद मिहलसिया
स्रोत
4
गतिरोध की तुलना में लॉकआउट टाइमआउट अलग नहीं है? उदाहरण के लिए यदि एक धागा वैध कारणों से 60 सेकंड के लिए लॉक रखता है तो लॉक प्रतीक्षा समय समाप्त हो सकता है। क्या यह सच नहीं है कि अगर वास्तव में कोई गतिरोध है MySQL इस का पता लगाएगा और तुरंत लेनदेन को मार देगा और यह लॉक वेट टाइमआउट से संबंधित नहीं है?
— कॉलिनम
1
तुम सही हो। DB समय-समय पर डेड-लॉक का पता लगाता है और एक प्रतीक्षा प्रक्रिया को मारता है, इसलिए एक लेनदेन जीत जाता है जबकि दूसरा विफल हो जाता है। लेकिन जितनी देर आप एक लॉक पकड़ेंगे उतना कम स्केलेबल एप्लिकेशन प्राप्त होता है। यहां तक ​​कि अगर आप मृत-तालों में नहीं चलते हैं, तब भी आप अपने एप्लिकेशन रनटाइम व्यवहार के क्रमिक भाग को बढ़ाएंगे।
— व्लाद मिहालसी
19

रिकॉर्ड के लिए, लॉक वेट टाइमआउट अपवाद तब भी होता है जब कोई गतिरोध होता है और MySQL इसका पता नहीं लगा सकता है, इसलिए यह केवल समय समाप्त होता है। एक और कारण एक बहुत लंबी चलने वाली क्वेरी हो सकती है, जो हल / मरम्मत करना आसान है, हालांकि, और मैं यहां इस मामले का वर्णन नहीं करूंगा।

MySQL आमतौर पर गतिरोध से निपटने में सक्षम होता है यदि वे दो लेनदेन के भीतर "ठीक से" निर्मित होते हैं। MySQL तब सिर्फ एक लेन-देन को मारता / रोलबैक करता है जो कम तालों का मालिक है (कम महत्वपूर्ण है क्योंकि यह कम पंक्तियों को प्रभावित करेगा) और दूसरे को खत्म करने देता है।

अब, मान लीजिए कि दो प्रक्रियाएँ A और B और 3 लेनदेन हैं:

Process A Transaction 1: Locks X
Process B Transaction 2: Locks Y
Process A Transaction 3: Needs Y => Waits for Y
Process B Transaction 2: Needs X => Waits for X
Process A Transaction 1: Waits for Transaction 3 to finish

(see the last two paragraph below to specify the terms in more detail)

=> deadlock

यह एक बहुत ही दुर्भाग्यपूर्ण सेटअप है क्योंकि MySQL यह नहीं देख सकता है कि एक गतिरोध है (3 लेनदेन के भीतर फैला हुआ)। तो MySQL क्या है ... कुछ भी नहीं! यह बस इंतजार करता है, क्योंकि यह नहीं जानता कि क्या करना है। यह तब तक इंतजार करता है जब तक पहला अधिग्रहीत लॉक टाइमआउट से अधिक नहीं हो जाता है (प्रोसेस ए ट्रांसेक्शन 1: लॉक एक्स), फिर यह लॉक एक्स को अनब्लॉक करेगा, जो ट्रांजैक्शन 2 आदि को अनलॉक करता है।

कला यह पता लगाने के लिए है कि कौन सी (कौन सी क्वेरी) पहले लॉक (लॉक एक्स) का कारण बनती है। आप आसानी से देख पाएंगे ( show engine innodb status) कि Transaction 3 Transaction 2 का इंतजार कर रहा है, लेकिन आप यह नहीं देखेंगे कि Transaction 2 किस लेन-देन का इंतजार कर रहा है (Transaction 1)। MySQL Transaction से जुड़े किसी भी प्रकार के ताले या क्वेरी को प्रिंट नहीं करेगा। केवल संकेत यह होगा कि लेन-देन सूची ( show engine innodb statusप्रिंटआउट के) के सबसे निचले भाग पर , आप देखेंगे कि Transaction 1 स्पष्ट रूप से कुछ नहीं कर रहा है (लेकिन वास्तव में Transaction 3 की प्रतीक्षा कर रहा है) समाप्त)।

एसक्यूएल क्वेरी किस तरीके से खोजती है, इसके लिए लॉक (लॉक एक्स) दिए गए लेन-देन के लिए दी गई है जिसका इंतजार यहां वर्णित है Tracking MySQL query history in long running transactions

यदि आप सोच रहे हैं कि प्रक्रिया और लेनदेन क्या उदाहरण में है। प्रक्रिया एक PHP प्रक्रिया है। लेन-देन एक लेन-देन है जैसा कि innodb-trx-table द्वारा परिभाषित किया गया है । मेरे मामले में, मेरे पास दो PHP प्रक्रियाएं थीं, प्रत्येक में मैंने मैन्युअल रूप से लेनदेन शुरू किया। दिलचस्प हिस्सा यह था कि भले ही मैंने एक प्रक्रिया में एक लेन-देन शुरू किया था, MySQL आंतरिक रूप से वास्तव में दो अलग-अलग लेनदेन का उपयोग करता था (मेरे पास कोई सुराग नहीं है, शायद कुछ MySQL देव समझा सकते हैं)।

MySQL अपने स्वयं के लेन-देन को आंतरिक रूप से प्रबंधित कर रहा है और (मेरे मामले में) PHP प्रक्रिया (प्रोसेस ए) से आने वाले सभी SQL अनुरोधों को संभालने के लिए दो लेनदेन का उपयोग करने का निर्णय लिया है। Transaction 1 के समाप्त होने के लिए Transaction 1 की प्रतीक्षा करने वाला कथन एक आंतरिक MySQL बात है। MySQL "जानता था" लेनदेन 1 और लेनदेन 3 वास्तव में एक "लेनदेन" अनुरोध (प्रक्रिया ए से) के हिस्से के रूप में त्वरित किया गया था। अब पूरे "लेन-देन" को अवरुद्ध कर दिया गया था क्योंकि लेनदेन 3 ("लेनदेन" का एक उपखंड) अवरुद्ध था। क्योंकि "लेन-देन" लेनदेन 1 को समाप्त करने में सक्षम नहीं था ("लेनदेन" का एक उप-भाग) भी चिह्नित किया गया था और साथ ही साथ समाप्त नहीं हुआ था। यह मेरा मतलब है "लेन-देन 1 के लिए लेनदेन 3 समाप्त होने का इंतजार करता है"।

— टॉमस बिल्का
स्रोत
14

इस अपवाद के साथ बड़ी समस्या यह है कि इसका आमतौर पर परीक्षण के माहौल में प्रजनन योग्य नहीं होता है और जब हम ठेस पर होते हैं तो इनोडोड इंजन की स्थिति को चलाने के लिए आसपास नहीं होते हैं। इसलिए एक परियोजना में मैंने इस अपवाद के लिए नीचे दिए गए कोड को कैच ब्लॉक में डाल दिया। अपवाद होने पर मुझे इंजन की स्थिति को पकड़ने में मदद मिली। इससे बहुत मदद मिली।

Statement st = con.createStatement();
ResultSet rs =  st.executeQuery("SHOW ENGINE INNODB STATUS");
while(rs.next()){
    log.info(rs.getString(1));
    log.info(rs.getString(2));
    log.info(rs.getString(3));
}
— मारुथी
स्रोत
11

pt-deadlock-loggerउपयोगिता के आदमी पृष्ठ पर एक नज़र डालें :

brew install percona-toolkit
pt-deadlock-logger --ask-pass server_name

यह engine innodb statusउपर्युक्त से जानकारी निकालता है और इसका उपयोग daemonप्रत्येक 30 सेकंड में एक रन बनाने के लिए भी किया जा सकता है ।

— आंद्रेई सुरा
स्रोत
3
यह उपकरण अब Percona टूलकिट
— ब्रैड मेस
लॉक वेट टाइमआउट गतिरोध के समान नहीं हैं, विशेष रूप से निर्दोष उनके बारे में कोई जानकारी नहीं दिखाते हैं क्योंकि उन्हें गतिरोध का पता नहीं चलता है, इसलिए मुझे नहीं लगता कि पीटी-गतिरोध-लकड़हारा कोई मदद करता है।
— जे पैरोलिन
लॉक टाइमआउट और गतिरोध संबंधित हैं - देखें dev.mysql.com/doc/refman/5.7/en/innodb-deadlock-detection.html
— आंद्रेई सूरा
11

ऊपर रोलांडो के जवाब से बाहर निकालना, यह वह है जो आपकी क्वेरी को रोक रहा है:

---TRANSACTION 0 620783788, not started, process no 29956, OS thread id 1196472640
MySQL thread id 5341773, query id 189708353 10.64.89.143 viget

यदि आपको अपनी क्वेरी को निष्पादित करने की आवश्यकता है और दूसरों को चलाने के लिए इंतजार नहीं कर सकते, तो उन्हें MySQL थ्रेड आईडी का उपयोग करके मार दें:

kill 5341773 <replace with your thread id>

(mysql के भीतर से, शेल नहीं, जाहिर है)

आपको थ्रेड आईडी ढूंढनी होगी:

show engine innodb status\G

कमांड, और यह पता लगाएं कि डेटाबेस को ब्लॉक करने वाला कौन है।

— एलर्ट वैन कोपरेन
स्रोत
1
आप इसे कैसे जानते हैं 5341773? मैं नहीं देखता कि दूसरों से क्या अलग है।
— वोडिन
नहीं, यह शायद वह सूत्र नहीं है, यह एक उदाहरण था। आपको "शो इंजन इनोडोड स्टेटस \ G" कमांड से थ्रेड आईडी ढूंढनी होगी, और यह पता लगाना होगा कि डेटाबेस को ब्लॉक करने वाला कौन है।
— एलर्ट वैन कोपरेन
1
धन्यवाद। तो दूसरे शब्दों में, यह बताने का कोई तरीका नहीं है कि यह कौन सा है, जैसे कि उन्हें एक-एक करके मारना?
— वोडिन
लेन-देन की सूची में आप देख सकते हैं कि कौन से और कितने समय से चल रहे हैं। तो उन्हें एक-एक करके मारने की ज़रूरत नहीं है, यह सूची आमतौर पर आपको एक अच्छा विचार देती है कि क्या चल रहा है।
— एलर्ट वैन कोपरेन
10

यहाँ है कि मुझे अंततः यह पता लगाने के लिए क्या करना था कि "अन्य क्वेरी" लॉक टाइमआउट समस्या का कारण बनी। एप्लिकेशन कोड में, हम इस कार्य के लिए समर्पित एक अलग थ्रेड पर सभी लंबित डेटाबेस कॉल को ट्रैक करते हैं। यदि कोई DB कॉल N- सेकंड से अधिक समय लेता है (हमारे लिए यह 30 सेकंड है) तो हम लॉग करते हैं:

-- Pending InnoDB transactions
SELECT * FROM information_schema.innodb_trx ORDER BY trx_started; 

-- Optionally, log what transaction holds what locks
SELECT * FROM information_schema.innodb_locks;

ऊपर के साथ, हम समवर्ती प्रश्नों को इंगित करने में सक्षम थे जिन्होंने गतिरोध पैदा करने वाली पंक्तियों को बंद कर दिया था। मेरे मामले में, वे ऐसे बयान थे जैसे INSERT ... SELECTसादे चयनों के विपरीत अंतर्निहित पंक्तियों को लॉक करते हैं। फिर आप कोड को पुनर्गठित कर सकते हैं या किसी अन्य लेन-देन अलगाव का उपयोग कर सकते हैं जैसे कि बिना पढ़ा हुआ।

सौभाग्य!

— स्लावोमिर
स्रोत
9

आप उपयोग कर सकते हैं:

show full processlist

जो MySQL के सभी कनेक्शनों और कनेक्शन की वर्तमान स्थिति के साथ-साथ क्वेरी निष्पादित होने की सूची देगा। वहाँ भी एक छोटा संस्करण है show processlist;जो अलग-थलग क्वेरी और साथ ही कनेक्शन आँकड़े प्रदर्शित करता है।

— गेरिट ब्रिंक
स्रोत
-2

MySQL general.log (डिस्क सघन) को सक्रिय करें और लंबे समय से चल रहे लेनदेन को निकालने के लिए mysql_analyse_general_log.pl का उपयोग करें , उदाहरण के लिए:

--min-period = आपका innodb_lock_wait_time मान

उसके बाद सामान्य अक्षम करें।

— मिक
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.