MySQL त्रुटि> लॉक प्रतीक्षा टाइमआउट पार हो गया; लेनदेन को पुनरारंभ करने का प्रयास करें SQLState: 41000 विक्रेता त्रुटि: 1205

Question

मेरे पास यह वर्षों से जारी होने पर था और कभी भी इसके नीचे नहीं पहुंच पाया। मुझे नहीं पता कि इन ताले के कारण क्या हो सकता है।

त्रुटि है: Lock wait timeout exceeded; try restarting transaction SQLState: 41000 VendorError: 1205

SQL विवरण एक भी डालने बयान एक सौदे के भीतर चल रहा है। सभी आवेषण इस के रूप में हैं, इसलिए कोई थोक आवेषण और न ही मिश्रण मोड आवेषण आदि

INSERT INTO attachment( id, entityid, entitytype , addeduserid , deleteduserid , fullpath , filename, status, creationdate, lastupdated, deletiondate, hasfile,notes,history,type,mimeinfo,archivedby,archivedon, referencedate,changedby,changedon ) values (0,0,2,360,null,NULL,NULL,1,'2013-02-20 08:45:31','2013-02-20 08:45:31',NULL,0,NULL,'20/02/2013 08:45:UserA:File uploaded internally. <br>',0,NULL,null,NULL,NULL,null,NULL);

सिस्टम विन्यास: MySQL संस्करण: 'सर्वर संस्करण: 5.1.61 स्रोत वितरण' (redhat पर)

संग्रहण: InnoDB

InnoDB संबंधित विन्यास (आंशिक रूप से my.cnf से संपादित):

innodb_file_per_table=1 
innodb_buffer_pool_size=3G 
innodb_additional_mem_pool_size=20M 
innodb_log_file_size=512M 
innodb_log_files_in_group=2 
innodb_log_buffer_size=16M 
innodb_support_xa=1 
innodb_doublewrite=1 
innodb_thread_concurrency=0 
innodb_flush_log_at_trx_commit=2 
innodb_autoinc_lock_mode=2** 
innodb_rollback_on_timeout=1 
innodb_locks_unsafe_for_binlog=1** 
thread_cache_size=8 
query_cache_size=256M 
query_cache_limit=4M 
table_cache=2048 
table_definition_cache=1024 
tmp_table_size=512M 
max_heap_table_size=512M 
transaction-isolation=READ-COMMITTED** 
innodb_table_locks=0** 
innodb_lock_wait_timeout=50** 

** इन्हें विशेष रूप से इस मुद्दे के संबंध में जोड़ा गया है।

आम तौर पर:

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

आज जारी किए जाने की विशिष्ट उदाहरण:

attachment मेज पर आज सुबह, वहाँ कल रात के बाद से मेज पर एक डालने नहीं किया गया था। पिछली रात के बाद से टेबल पर कोई अपडेट नहीं था। यदि ताले अपडेट और आवेषण करने वाले अन्य उपयोगकर्ताओं से संबंधित नहीं हैं, तो कुछ निश्चित बयान ताले के कारण चुन सकते हैं? मैंने यह सुनिश्चित करने की कोशिश की है कि सभी चुनिंदा वक्तव्य attachment_general_index का उपयोग करें?

इस तथ्य के कारण कि मैं मुख्य रूप से इसे दो अलग-अलग तालिकाओं पर प्राप्त कर रहा हूं - यहां इस तालिका की संरचना है।

CREATE TABLE `attachment` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
`entityid` int(10) unsigned DEFAULT NULL, 
`entitytype` tinyint(3) unsigned NOT NULL DEFAULT '0', 
`addeduserid` int(10) unsigned NOT NULL, 
`deleteduserid` int(10) unsigned DEFAULT NULL, 
`fullpath` varchar(255) DEFAULT NULL, 
`filename` varchar(255) DEFAULT NULL, 
`status` tinyint(3) unsigned NOT NULL DEFAULT '0', 
`creationdate` varchar(40) DEFAULT NULL, 
`lastupdated` varchar(40) DEFAULT NULL, 
`deletiondate` varchar(40) DEFAULT NULL, 
`hasfile` tinyint(3) unsigned NOT NULL DEFAULT '0', 
`notes` text, 
`history` text, 
`type` tinyint(3) unsigned DEFAULT '0', 
`lastupdatedby` int(10) DEFAULT '0', 
`lastupdatedinfo` varchar(255) DEFAULT NULL, 
`mimeinfo` varchar(255) DEFAULT NULL, 
`archivedby` int(10) unsigned DEFAULT NULL, 
`archivedon` varchar(40) DEFAULT NULL, 
`referencedate` varchar(40) DEFAULT NULL, 
`changedby` int(10) unsigned DEFAULT NULL, 
`changedon` varchar(40) DEFAULT NULL, 
PRIMARY KEY (`id`), 
KEY `attachment_addeduserid_fkey` (`addeduserid`), 
KEY `attachment_deleteduserid_fkey` (`deleteduserid`), 
KEY `attachment_archivedby_fkey` (`archivedby`), 
KEY `attachment_changedby_fkey` (`changedby`), 
KEY `attachment_general_index` (`entitytype`,`entityid`,`status`,`type`), 
CONSTRAINT `attachment_ibfk_1` FOREIGN KEY (`addeduserid`) REFERENCES `user` (`id`), 
CONSTRAINT `attachment_ibfk_2` FOREIGN KEY (`deleteduserid`) REFERENCES `user` (`id`), 
CONSTRAINT `attachment_ibfk_3` FOREIGN KEY (`archivedby`) REFERENCES `user` (`id`), 
CONSTRAINT `attachment_ibfk_4` FOREIGN KEY (`changedby`) REFERENCES `user` (`id`) 
) ENGINE=InnoDB AUTO_INCREMENT=3619 DEFAULT CHARSET=latin1$$ 

मैं हाल ही में एक शो InnoDB स्थिति संलग्न किया है, यह आज से है और वहाँ कल से एक ताला इंतजार नहीं किया गया है। मैं इस आउटपुट के सभी को समझ नहीं पा रहा हूं, लेकिन मुख्य बात यह है कि ताले यहां कभी दिखाई नहीं देते हैं। मुझे लगता है कि उन्हें डेडलॉक्स के रूप में वर्गीकृत नहीं किया गया है?

https://docs.google.com/document/d/1Hslf2B594n8ofAUYxN54Gh8FrSCIFNGGMtthVI_Lv4k/pub

यह केवल मृत ताले क्षेत्र है कि इस समस्या के लिए दिलचस्प है है? यदि अन्य क्षेत्र हैं तो मैं इसे इकट्ठा करने की कोशिश करूंगा और यह प्रदान कर सकता है।

किसी भी मदद की सराहना की जाएगी।

निक

Answer 1

(यह शायद एक टिप्पणी होना चाहिए, लेकिन मैं जिस तरह से बहुत अधिक पाठ है, और स्वरूपण की जरूरत है)।

मुझे लगता है कि यह एक described at जहां काफ़ी मिलती-जुलती मुद्दा है:

1. एक लेन-देन एक मेज के अंत में एक ताला है।
2. एक दूसरे लेनदेन में अधिकांश तालिका में लॉक होता है।
3. पहला लेनदेन दूसरे लेनदेन द्वारा लॉक में अपडेट/डालने का प्रयास करता है। यह विफल रहता है इसलिए लेनदेन में से एक को मरने के लिए चुना जाता है।

show status पोस्ट करने के लिए धन्यवाद। आप सही हैं कि दिखाया गया डेडलॉक उस तालिका से संबंधित प्रतीत नहीं होता है, जिसे आप पूछ रहे थे, लेकिन ऐसा लगता है कि एक्सपर्ब में एक जैसा ही लगता है।

Is it only the dead locks area that is interesting for this issue?

हाँ, सटीक भागों हैं:

Transaction 1 

UPDATE operative SET lastupdated='2013-02-19 17:12:44'=N<EDITED> RECORD LOCKS space id 1789 page no 3622 n bits 112 index `PRIMARY` of table `<EDITED> `.`operative` trx id 0 233901602 lock_mode X locks rec but not gap waiting 

*** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 1789 page no 3622 n bits 112 index `PRIMARY` of table `<EDITED> `.`operative` trx id 0 233901602 lock_mode X locks rec but not gap waiting 


Transaction 2 

INSERT INTO opdate(operativeId,opdate,updatingUser,dategroup,type,notes,lastupdated) values (....) RECORD LOCKS space id 1789 page no 3622 n bits 112 index `PRIMARY` of table `<EDITED> `.`operative` trx id 0 233901603 lock mode S locks rec but not gap 


*** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 830 page no 112 n bits 808 index `opdate_unique` of table `<EDITED> `.`opdate` trx id 0 233901603 lock mode S waiting Record lock, heap no 739 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 

यह बहुत xaprb में सूचीबद्ध समस्या के समान लगता है। यानी

1. लेनदेन 2 ने तालिका में एक सम्मिलन किया है, और अब प्राथमिक कुंजी पर लॉक रखता है।
2. लेनदेन 1 अपडेट करने के लिए टेबल स्कैन कर रहा है और उस प्राथमिक कुंजी पर लॉक की प्रतीक्षा कर रहा है।
3. लेन-देन 2 एक और डालने करने के लिए कोशिश कर रहा है, और एक ताला होने की जरूरत है, लेकिन ऐसा करने की वजह से लेन-देन 1 पहले से ही है (मैं वास्तव में वहाँ अनुमान लगा रहा हूँ के रूप में आप तालिका नाम अस्पष्ट) से रोका जाता है।

मैं इस डेडलॉक को पहले ठीक करने के साथ-साथ आप जिस समस्या के बारे में पूछ रहे थे उसे ठीक करने का प्रयास करने का सुझाव दूंगा।

वास्तव में, मुझे लगता है कि आपकी समस्या INNODB स्थिति में प्रकट नहीं हो सकती है। आपको त्रुटि कोड 1205 मिल रहा है - जो ER_LOCK_WAIT_TIMEOUT है, त्रुटि 1213 ER_LOCK_DEADLOCK त्रुटि नहीं है। तो यद्यपि आप प्रभावी ढंग से एक डेडलॉक है, यह इस तरह वर्गीकृत नहीं किया जा रहा है।

मुझे लगता है कि यदि समस्या हो रही है, तो आप SHOW ENGINE INNODB STATUS कर सकते हैं, तो आप वहां पर स्थगित लेनदेन पर ताले देख सकते हैं, भले ही वे नवीनतम डेडलॉक के रूप में नहीं दिख रहे हों।

Answer 2

मैं उन लोगों के साथ अपना "यूरेका" पल साझा करना चाहता हूं जो लेन-देन के समय पर आपके सिर खरोंच कर रहे हैं और पाया है कि सुझाए गए सर्वर कॉन्फ़िगरेशन में से कोई भी मदद नहीं करता है।

मैं उस बिंदु पर झुका रहा था जहां मैं अपने कुछ एप्लिकेशन को दोबारा लिखने पर गंभीरता से विचार कर रहा था, इसलिए मैं लेनदेन समय-सारिणी को समायोजित कर सकता था (दुनिया भर में सामूहिक ग्रोन सुनाई देता है)।

मैं अपने व्यापार लेनदेन से कुछ खोने के बारे में पागल हूं इसलिए मैं एक क्रॉन नौकरी चलाता हूं जो पूरे 10 मिनट में पूर्ण mysqldump करता है (यह दोहरी प्रतिकृति के शीर्ष पर है)।

जो मैंने पाया था वह mysqldump सर्वर को हॉग करता है, टेबल लॉक करता है, और यह कुछ भी करने के दौरान डेटाबेस का उपयोग करने से कहीं ज्यादा कुछ भी मना करता है। मेरा यूरेका पल आया जब मैंने पाया कि लेनदेन विफलताओं mysqldump रन टाइम के साथ मेल खाता है।

लंबी कहानी छोटी 3 कमांड लाइन विकल्प हैं जो mysqldump को आपके सर्वर को मारने से रोकेंगी।ये

1. --एकल-लेन-देन
2. --quick
3. --lock-टेबल = मुझे ज्ञानवर्धक के लिए @How can I slow down a MySQL dump as to not affect current load on the server? CA3LE को गलत

बहुत धन्यवाद कर रहे हैं।