MySQL Deadlock отладка информации - PullRequest
Новая
       19

MySQL Deadlock отладка информации

0 голосов
/ 14 мая 2019

У меня есть 2 таблицы ЭКСПЕРИМЕНТ и ЛИЦА. ENTITIES имеет поле id, которое ссылается на первичный идентификатор таблицы EXPERIMENT.

Я вставил несколько экспериментов одновременно с дочерними объектами и получил тупики.

show engine innodb status показывает информацию об отладке. Я не могу понять, почему возникла тупиковая ситуация. Я предполагаю, что это произошло потому, что дочерние объекты проверяют Foreign_Key в экспериментальной таблице, но это не похоже на то, что это должно вызвать тупик.

Я использую AUTO INCREMENT для идентификации идентификатора и SERIALIZABLE транзакции.

Вот соответствующий раздел из статуса innodb: 

------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-05-14 12:34:45 0x7000060f3000
*** (1) TRANSACTION:
TRANSACTION 162916, ACTIVE 1 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 10 lock struct(s), heap size 1136, 6 row lock(s), undo log entries 2
MySQL thread id 183, OS thread handle 123145405919232, query id 2464 localhost 127.0.0.1 root update
INSERT INTO _ENTITIES (TYPE, FK_EXPERIMENT_ID, CONTENT, CREATED_USER_ID) VALUES ('VARIATION', 42, '{"variantName":"Variant 1","actions":[{"blockId":0,"type":"SendEmail","criteria":{"and":[{"operator":"EQ","attr":"_id","val":"Test","ruleId":1,"category":"default"},{"operator":"EQ","attr":"productLanguage","val":"CS_CZ","ruleId":1,"category":"contextual"}]},"order":1,"surfaceActionName":"EMAIL","params":{"verified":true,"selectedTemplate":"Design-Paid-Portfolio-A"},"name":"Action Block 1","treatmentId":"","default":true},{"blockId":1,"type":"wait","criteria":{"and":[{"operator":"EQ","attr":"_id","val":"Test","ruleId":1,"category":"default"},{"operator":"EQ","attr":"productLanguage","val":"CS_CZ","ruleId":1,"category":"contextual"}]},"order":1,"surfaceActionName":"wait","params":{"unit":"hour","data":10,"verified":true},"name":"Action Block 1","treatmentId":"","default":true}],"variantPercentage":80}', 'uk
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 6728 page no 4 n bits 96 index ENTITIES_EXPERIMENT_ID of table `test_database`.`_entities` trx id 162916 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) TRANSACTION:
TRANSACTION 162906, ACTIVE 1 sec inserting
mysql tables in use 1, locked 1
8 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 2
MySQL thread id 164, OS thread handle 123145403969536, query id 2549 localhost 127.0.0.1 root update
INSERT INTO _ENTITIES (TYPE, FK_EXPERIMENT_ID, CONTENT, CREATED_USER_ID) VALUES ('VARIATION', 33, '{"variantName":"Variant 1","actions":[{"blockId":0,"type":"SendEmail","criteria":{"and":[{"operator":"EQ","attr":"_id","val":"Test","ruleId":1,"category":"default"},{"operator":"EQ","attr":"productLanguage","val":"CS_CZ","ruleId":1,"category":"contextual"}]},"order":1,"surfaceActionName":"EMAIL","params":{"verified":true,"selectedTemplate":"Design-Paid-Portfolio-A"},"name":"Action Block 1","treatmentId":"","default":true},{"blockId":1,"type":"wait","criteria":{"and":[{"operator":"EQ","attr":"_id","val":"Test","ruleId":1,"category":"default"},{"operator":"EQ","attr":"productLanguage","val":"CS_CZ","ruleId":1,"category":"contextual"}]},"order":1,"surfaceActionName":"wait","params":{"unit":"hour","data":10,"verified":true},"name":"Action Block 1","treatmentId":"","default":true}],"variantPercentage":80}', 'uk
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 6728 page no 4 n bits 96 index ENTITIES_EXPERIMENT_ID of table `test_database`.`_entities` trx id 162906 lock mode S
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 6728 page no 4 n bits 96 index ENTITIES_EXPERIMENT_ID of table `test_database`.`_entities` trx id 162906 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** WE ROLL BACK TRANSACTION (2)
------------

Как мне это интерпретировать и почему возникла тупиковая ситуация?

Используемый код: 

Integer generatedId = experimentDAO.add(experimentQO);
......

for..
    entitiesDAO.add(entitiesQO);
....
ExperimentQO experimentQO = experimentDAO.get(generatedId);

При добавлении сущности возникает исключение.

1 Ответ

0 голосов
/ 14 мая 2019

Я вижу следующее:

  • Trx # 1 ожидает блокировки намерения вставки в режиме X (своего рода блокировка пробела) в индексе ENTITIES_EXPERIMENT_ID.
  • Trx # 2содержит S-блокировку для индекса ENTITIES_EXPERIMENT_ID, который блокирует Trx # 1
  • Trx # 2 также ожидает блокировки намерения вставки для индекса ENTITIES_EXPERIMENT_ID.

Можно предположить, что Trx# 1 также удерживает S-блокировку на том же индексе.S-блокировки являются общими, поэтому несколько транзакций могут одновременно получать S-блокировки в одной и той же строке (или гэпе).

Если обе транзакции сначала получили S-блокировки, а затем обе попытались запросить X-блокировки, они бы вступили вситуация, когда оба ожидали другого, без возможности выхода из тупика.

Возможно, что оба оператора INSERT получили S-блокировки в качестве первого шага.Или возможно, что вы выполняли некоторые другие запросы, которые получают S-блокировки в той же транзакции до INSERT, поэтому обе транзакции все еще удерживают свои соответствующие S-блокировки.

Вы не показали определение таблицы, поэтомуЭто могут быть ограничения внешнего ключа, которые могут привести к получению блокировок S для строк, на которые ссылаются косвенно.

...