Этот тупик InnoDB действительно заставляет меня тянуть мои волосы. Насколько я могу видеть:Baffling InnoDB тупик
сделка (1) ждет ПЕРВИЧНОГО на «приложения»
Последний был приобретен (2) для некоторых довольно долго работает обновлений (SELECT * FROM приложений WHERE ID = хххх FOR UPDATE)
до сих пор, так хорошо - можно было бы ожидать (1) ждать замка, а затем получить на свою работу.
Однако один раз (2) готов к сохранению его работы (и совершить транзакцию), он не работает с тупиком, так как по какой-то причине (1) удалось получить блокировку некоторого вторичного индекса. Как, черт возьми, (1) удалось получить блокировки в строке, если PRIMARY удерживается (2).
Можно было бы ожидать, что если (2) изначально приобрела блокировку PRIMARY (SELECT * FROM applications WHERE ID = xxxx FOR UPDATE), она также установила блокировки для всех вторичных индексов. Возможно ли, что он не будет блокировать «заданный» индекс, если задано значение == NULL, таким образом позволяя (1) получить блокировку на «заданной» до того, как получит блокировку PRIMARY?
Я никогда не имел удачи репликации этот сценарий ..
Спасибо!
Лаури
------------------------
LATEST DETECTED DEADLOCK
------------------------
130428 17:04:06
*** (1) TRANSACTION:
TRANSACTION A369A8C, ACTIVE 1 sec fetching rows
mysql tables in use 3, locked 3
LOCK WAIT 217 lock struct(s), heap size 31160, 636 row lock(s)
MySQL thread id 13310554, OS thread handle 0x7f06cc2d7700, query id 177699568 217.146.78.151 shard67 Sending data
SELECT `applications`.* FROM `applications`
LEFT JOIN `applicants` ON applicants.ID = applications.applicant_ID
LEFT JOIN `regions` ON regions.ID = applicants.region_ID WHERE (status <> 'Blank') AND (status <> 'Closed') AND (revised < 1367154245) AND (tasked IS NULL OR tasked < 1367147045) AND (commence_year >= '2013') AND (regions.instance_ID = '1') ORDER BY `tasked` ASC, `ID` ASC LIMIT 20 FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 20021 page no 1192 n bits 80 index `PRIMARY` of table `dream-shard67`.`applications` trx id A369A8C lock_mode X locks rec but not gap waiting
*** (2) TRANSACTION:
TRANSACTION A369A87, ACTIVE 1 sec updating or deleting
mysql tables in use 1, locked 1
16 lock struct(s), heap size 3112, 22 row lock(s), undo log entries 5
MySQL thread id 13310563, OS thread handle 0x7f06cc151700, query id 177699599 217.146.76.127 shard67
UPDATE `applications` SET `revised` = '1367157846', `tasked` = '1367157846', `revision_ID` = '140649', `xml` = 'Zms6\noMmI$%[v....snipped binary data
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 20021 page no 1192 n bits 72 index `PRIMARY` of table `dream-shard67`.`applications` trx id A369A87 lock_mode X locks rec but not gap
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 20021 page no 292 n bits 1280 index `tasked` of table `dream-shard67`.`applications` trx id A369A87 lock_mode X locks rec but not gap waiting
*** WE ROLL BACK TRANSACTION (2)