Календарь на Май 2024 года: calendar2008.ru/2024/may/
Навигация
Главная »  Sql 

Немного про Deadlock


Источник: habrahabr
zim32
Это совсем краткий пост о причинах возникновения Deadlock В более менее нагруженных проектах, использующих транзакции InnoDB, в любой момент может возникнуть ошибка вида "Deadlock found when trying to get lock; try restarting transaction" Главное не паниковать при виде этих страшных слов, сейчас мы разберемся почему это происходит.
Немного о типах блокировок В оффициальной документации Mysql про типы блокировок написано совсем немного, а именно: Есть 2 типа блокировок - Shared (S) и Exclusive (X). Первый тип позволяет только читать данные прикрытые этой блокировкой, второй - читать, писать, удалять и (о чем скромно умолчали) - получить блокировку уровня S Так же сказано что если Транзакция№1 владеет блокировкой типа S на строке r, то другая Транзакция№2 может захватить эту блокировку. Чтобы получить блокировку типа X на этой строке, второй транзакции придется тихо подождать в сторонке. Если же Транзакция№1 владеет блокировкой типа X на строке r, то Транзакция№2 не может ни захватить эту же блокировку, ни получить новую уровня S. Она опять тихо идет и ждет пока Транзакция№1 освободит требуемую строку. Здесь есть один важный момент, который необходимо усвоить: блокировки S и X - это 2 разные блокировки. Это не значит что блокировка S, это какое-то подмножество блокировки X. Это две разных сущности. Вернемся к дедлокам. На некоторых форумах я встречал вопросы "Как получит deadlock в Mysql". На самом деле очень просто. Все необходимы ингредиенты у нас имеются в наличии: две транзакции, блокировки типа S и X и строка, на которую получают блокировки. Краткий рецепт приготовления deadlock на одной строке
1) Транзакция№1 получает блокировку S и продолжает работу
2) Транзакция№2 пытается получить блокировку типа X и… начинает ждать когда Транзакция№1 освободит блокировку S
3) Транзакция№1 пытается получить блокировку типа X и… начинает ждать когда Транзакция№2 получит блокировку типа X и освободит её Блюдо подано Тут есть один скользкий момент. Казалось бы что мешает Транзакции№1 получить блокировку X если она уже имеет блокировку S на этой же строке. А мешает то о чем мы говорили 
1) Во-первых X и S это две разных блокировки
2) Во-вторых блокировка типа S не дает право на получение блокировки типа X. Никаких привилегий - в очередь! Код для ситуации выше Transaction #1
BEGIN; SELECT * FROM `testlock` WHERE id=1 LOCK IN SHARE MODE; /* GET S LOCK */ SELECT SLEEP(5); SELECT * FROM `testlock` WHERE id=1 FOR UPDATE; /* TRY TO GET X LOCK */ COMMIT; 

Transaction #2
BEGIN; SELECT * FROM `testlock` WHERE id=1 FOR UPDATE; /* TRY TO GET X LOCK - DEADLOCK AND ROLLBACK HERE */ COMMIT; 
Как же с этим бороться? Офф. сайт Mysql советует комититься почаще, а так же перепроверять код ошибки и перепроводить откатившуюся транзакцию. Мне кажется есть вариант получше - сразу получать блокировку типа X. Тогда на третьем шаге нашего рецепта Транзакция№1 смогла бы получить свою законную блокировку и спокойно завершиться Напоследок скажу что определить причину deadlock поможет команда  SHOW ENGINE INNODB STATUS , которая показывает какие блокировки кто держит и какие ожидает



 

 Формирование хранимых шаблонов в Oracle 9.
 Oracle_trace - лучшее встроенное средство диагностики.
 Первичный ключ - составной или суррогатный?.
 Мониторинг использования индексов в планах запросов в Oracle 10g.
 Снова аналитические функции.


Главная »  Sql 

© 2024 Team.Furia.Ru.
Частичное копирование материалов разрешено.