MySql錯誤>鎖超時超時;嘗試重新啓動事務SQLState：41000 VendorError：1205

Question

我有這個持續多年的問題，從來沒有能夠達到它的底部。我不知道是什麼可能導致這些鎖。

的錯誤是：Lock wait timeout exceeded; try restarting transaction SQLState: 41000 VendorError: 1205

的SQL語句是在一個事務中運行一個INSERT語句。所有刀片是這種形式的，所以沒有批量插入，也沒有混合模式插入等

​​

系統配置： MySQL的版本：「服務器版本：61年1月5日來源分佈」（在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** 

**這些已被具體添加在這個問題上。

一般：

系統（即具有每上一個MySQL實例都運行相同的數據庫結構6個應用實例）可以運行罰款天，然後可以有一個運行在那裏的鎖等待開始出現時，並通常會讓他們在一天中出現在小組中。每個單獨的錯誤都會重複發生，因爲一旦失敗，我將再次嘗試，通常重新嘗試將失敗。我已配置重試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$$ 

我附上最近SHOW INNODB STATUS，這是從今天還沒有從昨天開始鎖等待。我不明白所有這些輸出，但主要的是鎖從未出現在這裏。我認爲他們沒有被歸類爲死鎖？

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

難道只有死鎖地區，是有趣的這個問題？如果有其他地區，我會盡量收集，當它發生並可以提供。

任何幫助，將不勝感激。

尼克

Answer 1

（這也許應該是一個評論，但我有太多的文字，需要格式化）。

我認爲這是一個非常類似的問題的一個described at其中：

1. 一個交易都有在表的末尾上的鎖。
2. 第二個事務鎖定了大部分表。
3. 第一個事務嘗試更新/插入第二個事務持有的鎖。這會失敗，因此選擇其中一個事務處理。

感謝發佈show status。你說得對，所顯示的僵局似乎與你所詢問的表格沒有關係，但它看起來與Xaprb的相同。

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

我想與那些在交易超時時間頭痛不已的人一起分享我的「尤里卡」時刻，並發現建議的服務器配置更改沒有任何幫助。

我很掙扎，以至於我認真考慮重新編寫一些應用程序，這樣我就可以適應事務超時（一個集體的呻吟聽起來「環遊世界」）。

我對從業務事務中丟失任何東西有偏見，所以我運行一個cron作業，每隔10分鐘執行一次完整的mysqldump（這是雙重複制）。

我發現的是mysqldump佔用了服務器，鎖定了表，並且幾乎禁止使用數據庫的其他任何事情。當我發現交易失敗與mysqldump運行時間一致時，我的尤里卡時刻到來了。

長話短說有3個命令行選項可以防止mysqldump殺死你的服務器。這些都是

1. --single事務
2. --quick
3. --lock桌=假

非常感謝CA3LE @How can I slow down a MySQL dump as to not affect current load on the server?爲啓發我。