2011-03-28 17 views
14

'शो इंजन innodb स्थिति' का उपयोग करके मैं देखता हूं कि वर्डप्रेस में दो डेडलॉक्स हैं। मैं इन्हें साफ़ करना चाहता हूं लेकिन मुझे इन cmds में से किसी एक के लिए सक्रिय प्रक्रिया नहीं दिखाई दे रही है (आईई कुछ 'मारने' और उम्मीद है कि रोलबैक को मजबूर कर दें)।साफ़ लेनदेन डेडलॉक?

मैं थ्रेड आईडी, क्वेरी आईडी, आदि देख सकता हूं लेकिन कुछ भी नहीं जो मैं नौकरी को रोकने के लिए उपयोग कर सकता हूं।

इसे हल करने के तरीके पर सुझाव?

संपादित करें:

------------------------ 
LATEST DETECTED DEADLOCK 
------------------------ 
110327 10:54:14 
*** (1) TRANSACTION: 
TRANSACTION 9FBA099E, ACTIVE 0 sec, process no 14207, OS thread id 1228433728 starting index read 
mysql tables in use 1, locked 1 
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s) 
MySQL thread id 12505112, query id 909492800 juno....edu 129....54 wordpress_user updating 
DELETE FROM wp_options WHERE option_name = ''_site_transient_timeout_theme_roots'' 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 4951009 page no 4 n bits 384 index `option_name` of table `wordpress_work`.`wp_options` trx id 9FBA099E lock_mode X waiting 
Record lock, heap no 309 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 
0: len 30; hex 5f736974655f7472616e7369656e745f74696d656f75745f7468656d655f; asc _site_transient_timeout_theme_; (total 35 bytes); 
1: len 8; hex 0000000000002b6d; asc  +m;; 

*** (2) TRANSACTION: 
TRANSACTION 9FBA0995, ACTIVE 0 sec, process no 14207, OS thread id 1230031168 starting index read 
mysql tables in use 1, locked 1 
3 lock struct(s), heap size 1248, 2 row lock(s) 
MySQL thread id 12505095, query id 909492789 juno....edu 129.....54 wordpress_user updating 
DELETE FROM wp_options WHERE option_name = ''_site_transient_timeout_theme_roots'' 
*** (2) HOLDS THE LOCK(S): 
RECORD LOCKS space id 4951009 page no 4 n bits 384 index `option_name` of table `wordpress_work`.`wp_options` trx id 9FBA0995 lock_mode X locks rec but not gap 
Record lock, heap no 309 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 
0: len 30; hex 5f736974655f7472616e7369656e745f74696d656f75745f7468656d655f; asc _site_transient_timeout_theme_; (total 35 bytes); 
1: len 8; hex 0000000000002b6d; asc  +m;; 

*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 4951009 page no 4 n bits 384 index `option_name` of table  `wordpress_work`.`wp_options` trx id 9FBA0995 lock_mode X waiting 
Record lock, heap no 309 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 
0: len 30; hex 5f736974655f7472616e7369656e745f74696d656f75745f7468656d655f; asc _site_transient_timeout_theme_; (total 35 bytes); 
1: len 8; hex 0000000000002b6d; asc  +m;; 

*** WE ROLL BACK TRANSACTION (1) 
+0

'किल क्वेरी-आईडी 'काम करना चाहिए? – Konerak

+0

लेकिन कहा गया है कि 'शो प्रोसेसलिस्ट' – ethrbunny

+0

के माध्यम से क्वेरी दिखाई नहीं देती है, मुझे लगता है कि आपको –

उत्तर

19

इस तरह की कुछ 'InnoDB स्थिति' उत्पादन को देखते हुए:: यहाँ (? प्रासंगिक) की स्थिति के भाग है

---TRANSACTION 0 0, not started, process no 1024, OS thread id 140386055603968 
MySQL thread id 197, query id 771 localhost marc 
show innodb status 

आप क्या करना चाहते चाहते हैं

KILL QUERY 771 

मृतक वाले दो प्रश्नों में से एक को मारने के लिए। वह क्वेरी को मार देगा, लेकिन कनेक्शन को खुला छोड़ दें। अगर आप कनेक्शन को मारना चाहते हैं, तो आप KILL 197 करेंगे।

+3

'अज्ञात थ्रेड आईडी' या तो मूल्य की कोशिश कर रहा है। – ethrbunny

+2

यह mysql के नए संस्करणों में 'इंजन इंजन innodb स्थिति' होना चाहिए, मैं 5.6.10 पर हूं और 'innodb स्थिति दिखाएं' वैध आदेश नहीं है। –

+3

मैं इसी तरह की स्थिति से मुलाकात की। यह 'शो' कमांड सिंटैक्स के बारे में नहीं है। चूंकि 'शो प्रोसेसलिस्ट' इन प्रश्नों से संबंधित कोई कनेक्शन नहीं दिखाती है, इसका मतलब है कि इन डेडलॉक लेन-देन स्टोरेज इंजन के स्तर पर बनाए जाते हैं, न कि MySQL API के स्तर पर। इस तरह की चीजों को हल करने का एकमात्र तरीका यह है कि MySQL की सेवा को पुनरारंभ करना है। – Sender

7

मुझे पता है कि यह पुराना है, लेकिन आम तौर पर जब आप ऐसा कुछ देखते हैं तो ऐसा इसलिए होता है क्योंकि एक डेडलॉक हुआ और डेडलॉक ट्रिगर करने वाला ऐप लंबे समय से आगे बढ़ गया है - डेडलॉक के शिकार को चेतावनी दी गई है और या तो असफल हो गया है, या लॉग है एक त्रुटि या पुनः प्रयास किया गया, और किसी भी तरह से अन्य उत्पादक चीजों पर चला गया है। यदि आप सॉफ़्टवेयर लिख रहे हैं, तो आपको आमतौर पर डेडलॉक के कारण को देखने के अलावा कुछ भी करने की ज़रूरत नहीं है और भविष्य के डेडलॉक्स से बचने और उससे बचने की कोशिश नहीं की जाती है। यदि आप केवल सॉफ्टवेयर का उपयोग कर रहे हैं (उदा। वर्डप्रेस अगर आप वर्डप्रेस पर काम नहीं करते हैं), तो आप संभावित बग के रूप में डेडलॉक की रिपोर्ट कर सकते हैं।

4

'शो इंजन innodb स्थिति' का उपयोग करके मैं देखता हूं कि वर्डप्रेस में दो deadlocks है ... इसे हल करने के सुझाव पर सुझाव?

सोचा था कि मैं कुछ और जानकारी प्रदान करूंगा जो हमें एक ही समस्या को हल करने में मदद करता। हम जावा हाइबरनेट मुद्दों को देख रहे थे जिससे फंसे हुए ताले थे। हमने ताले को आउटपुट से जोड़कर ताले लगाए:

show engine innodb status; 

यह जानकारी का एक बकवास-बाहर निकलता है। प्रासंगिक अनुभाग TRANSACTIONS अनुभाग में है। अपने उत्पादन में प्रासंगिक समस्या लगती है:

3 lock struct(s), heap size 1248, 2 row lock(s) 
MySQL thread id 12505095, query id 909492789 juno....edu 129.....54 

हमारे लिए यह # lock struct(s) कि एक अटक ताला संकेत दिया था। यह मारने के लिए आप "धागा आईडी #" निर्दिष्ट का उपयोग करके निष्पादित करने के लिए की जरूरत है - इस मामले में:

kill 12505095 

यह एडब्ल्यूएस MySQL आरडीएस पर काम किया स्थानीय MySQL के साथ ही।


हमारे लेनदेन में खंड हम भी निम्न देखें:

---TRANSACTION 644793773, ACTIVE 21 sec 
2 lock struct(s), heap size 360, 1 row lock(s) 
MySQL thread id 217, OS thread handle 0x2aef097700, query id 10177 1.3.5.7 mpsp cleaning up 

हम दोनों 2 lock struct(s) और ACTIVE 21 sec संदेशों के लिए देखें।

संबंधित मुद्दे