Почему мои тупики не отображаются в SHOW ENGINE INNODB STATUS;?

У меня есть MariaDB (5.5.41) кластер, состоящий из 2 узлов, настроенных как ведущий-ведомый. Все операции чтения и записи отправляются на один и тот же узел.

Я изучал некоторые тупиковые ситуации в течение нескольких недель.

Регулярно мое приложение PHP возвращается Message: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction.

Я имел обыкновение бегать SHOW ENGINE INNODB STATUS; и увидит этот последний тупик, но по какой-то причине, после небольшого несоответствующего изменения конфигурации (изменение innodb_buffer_pool_instances от 1 до 19) и перезагрузите оба узла, выполнив SHOW ENGINE INNODB STATUS; не будет показывать тупик.

Однако, если я соединяюсь с моим клиентом mysql и вручную создаю транзакции, приводящие к взаимоблокировке, команда status показывает взаимоблокировку.

Я пытался играть innodb_print_all_deadlocks Включить и выключить. Ничто не показывает в mysql-error.log кроме моего вручную вызванного тупика.

Почему тупики, созданные моим PHP-приложением, больше не отображаются?

Источник

3 ответа

Я не думаю, что могу ответить на ваш вопрос напрямую, учитывая отсутствие доступа к вашим системам и предоставленную информацию. Тем не менее, вот некоторые инструменты AWESOME, которые я использовал, чтобы лучше справляться со всеми разновидностями баз данных на основе MySQL, которые мне поручено администрировать.

InnoTop: https://github.com/innotop/innotop

Проверьте команду "D" на странице справки innotop:

       D: InnoDB Deadlocks
           This mode shows the transactions involved in the last InnoDB
           deadlock.  A second table shows the locks each transaction held and
           waited for.  A deadlock is caused by a cycle in the waits-for
           graph, so there should be two locks held and one waited for unless
           the deadlock information is truncated. [...]

Команды "K" и "L" также могут иметь отношение к вам.

ПРИМЕЧАНИЕ: для полной полезности innotop может потребоваться изменить информацию и параметры схемы, а также добавить тестовую базу данных для сбора информации. ПРОЧИТАЙТЕ ВСЮ СТРАНИЦУ ЧЕЛОВЕКА, чтобы узнать, чем вы занимаетесь, прежде чем слепо менять свою базу данных. (Лично я люблю дополнительную информацию, которую обнародует innotop изменения...)

Менее непосредственно относится к вашей проблеме блокировки, но, тем не менее, очень полезно:

Набор инструментов Percona (ранее MAATKIT): https://www.percona.com/software/database-tools/percona-toolkit

Удачи!

Источник

Это довольно загадочно, что show engine innodb status не дает вам необходимую тупиковую информацию. Однако вы можете проверить наличие тупиков, запустив mysqladmin debug, который регистрирует все блокировки, а также блокировки LOCK TABLE, которые не отображаются show engine innodb status в этом случае.

Эти проблемы иногда возникают в неподходящее время, и это тратит много времени. Я лично использую Monyog для мониторинга, который также делает это. Вы можете попробовать использовать его пробную версию, если ничего не работает.

Источник

Что делать в разделе [mysqld] my.cnf/ini

innodb_print_all_deadlocks=ON  # for error log documentation & be proactive in correcting.
log_error=(a valid filename)  # to write to  RTM
innodb_buffer_pool_instances=8  # from 19 would be adequate RAM overhead
Источник
Другие вопросы по тегам