Как избежать тупика mysql, обнаруженного при попытке получить блокировку; попробуйте перезапустить транзакцию "

Ответ 1

Один простой трюк, который может помочь с большинством взаимоблокировок, - это сортировка операций в определенном порядке.

Вы получаете тупик, когда две транзакции пытаются заблокировать две блокировки с противоположными порядками, то есть:

• соединение 1: клавиша блокировки (1), клавиша блокировки (2);
• соединение 2: клавиша блокировки (2), клавиша блокировки (1);

Если оба запускаются одновременно, соединение 1 блокирует ключ (1), соединение 2 блокирует ключ (2), и каждое соединение будет ждать, пока другой отпустит ключ → тупик.

Теперь, если вы изменили свои запросы таким образом, чтобы соединения блокировали ключи в том же порядке, то есть:

• соединение 1: клавиша блокировки (1), клавиша блокировки (2);
• соединение 2: клавиша блокировки (1), клавиша блокировки ( 2);

невозможно будет зайти в тупик.

Так вот что я предлагаю:

• Убедитесь, что у вас нет других запросов, которые блокируют доступ к нескольким ключевым словам за раз, за ​​исключением инструкции удаления. если вы это сделаете (и я подозреваю, что вы это сделали), закажите их ГДЕ в (k1, k2,.. kn) в порядке возрастания.

• Исправьте оператор delete для работы в порядке возрастания:

Измените

DELETE FROM onlineusers WHERE datetime <= now() - INTERVAL 900 SECOND

Для

DELETE FROM onlineusers WHERE id IN (SELECT id FROM onlineusers
    WHERE datetime <= now() - INTERVAL 900 SECOND order by id) u;

Еще одна вещь, о которой следует помнить, заключается в том, что документация mysql предполагает, что в случае тупика клиент должен повторить попытку автоматически. вы можете добавить эту логику в свой код клиента. (Скажем, 3 попытки повторить эту ошибку перед тем, как сдаться).

Ответ 2

Тупик случается, когда две транзакции ожидают друг друга, чтобы получить блокировку. Пример:

• Tx 1: блокировка A, затем B
• Tx 2: заблокировать B, затем A

Существует множество вопросов и ответов о взаимоблокировках. Каждый раз, когда вы вставляете/обновляете/или удаляете строку, происходит блокировка. Чтобы избежать тупиковой ситуации, вы должны убедиться, что параллельные транзакции не обновляют строку в порядке, который может привести к тупиковой ситуации. Вообще говоря, попытайтесь получить блокировку всегда в том же порядке даже в разных транзакциях (например, всегда сначала таблицу A, затем таблицу B).

Другой причиной тупика в базе данных может быть отсутствующих индексов. Когда строка вставлена ​​/обновлена ​​/удалена, база данных должна проверять реляционные ограничения, то есть убедиться, что отношения согласованы. Для этого база данных должна проверять внешние ключи в связанных таблицах. Это может привести к приобретению другой блокировки, чем измененная строка. Убедитесь, что всегда есть индекс для внешних ключей (и, конечно, первичных ключей), иначе это может привести к блокировке таблицы вместо блокировки строк . Если происходит блокировка таблицы, конфликт блокировки выше и вероятность блокировки увеличивается.

Ответ 3

Вполне вероятно, что оператор delete будет влиять на большую часть общих строк в таблице. В конечном итоге это может привести к блокировке таблицы при удалении. Удержание блокировки (в данном случае row- или блокировки страниц) и получение большего количества блокировок всегда является фактором взаимоблокировки. Однако я не могу объяснить, почему оператор insert приводит к эскалации блокировки - возможно, это связано с разбиением/добавлением страницы, но кто-то, кто знает MySQL, должен будет заполнить его.

Для начала можно попытаться явно получить блокировку таблицы сразу для инструкции delete. См. ЛОКАЛЬНЫЕ ТАБЛИЦЫ и проблемы с блокировкой таблиц.

Ответ 4

Вы можете попробовать, чтобы это задание на delete работало, сначала вставив ключ каждой строки, которая будет удалена в временную таблицу, такую как псевдокод

create temporary table deletetemp (userid int);

insert into deletetemp (userid)
  select userid from onlineusers where datetime <= now - interval 900 second;

delete from onlineusers where userid in (select userid from deletetemp);

Прерывание этого, как это, менее эффективно, но это позволяет избежать блокировки ключа при delete.

Кроме того, измените ваши запросы select чтобы добавить предложение where, исключая строки старше 900 секунд. Это позволяет избежать зависимости от задания cron и позволяет перенастроить его на работу менее часто.

Теория о взаимоблокировках: у меня нет большого фона в MySQL, но здесь идет... delete будет содержать блокировку ключевого диапазона для datetime, чтобы предотвратить соответствие строк, where предложение where добавлено в середине транзакция, и поскольку она находит строки для удаления, она попытается получить блокировку на каждой странице, которую она модифицирует. insert собирается получить блокировку на странице, в которую она вставляется, а затем попытаться получить блокировку ключа. Обычно insert будет терпеливо ждать, пока эта блокировка клавиатуры не откроется, но это затормозит, если delete попытается заблокировать ту же страницу, которую использует insert потому что для delete требуется эта блокировка страницы, а insert нуждается в блокировке ключа. Это не похоже на вставки, но delete и insert используют диапазоны datetime, которые не перекрываются, поэтому, возможно, что-то еще происходит.

http://dev.mysql.com/doc/refman/5.1/en/innodb-next-key-locking.html

Ответ 5

Для программистов на Java, использующих Spring, я избежал этой проблемы, используя аспект AOP, который автоматически повторяет транзакции, которые запускаются в переходные тупики.

См. @RetryTransaction Javadoc для получения дополнительной информации.

Ответ 6

У меня есть метод, внутренности которого завернуты в MySqlTransaction.

Вопрос о тупике появился для меня, когда я запускал тот же метод параллельно с собой.

Не было проблемы с запуском одного экземпляра метода.

Когда я удалил MySqlTransaction, я смог запустить этот метод параллельно с собой без проблем.

Просто поделившись своим опытом, я ничего не пропагандирую.