Вопросы Теги

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

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

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

На регулярной основе мое приложение PHP возвращает Сообщение: SQLSTATE [40001]: сбой сериализации : 1213 Обнаружена тупиковая ситуация при попытке получить блокировку; попробуйте перезапустить транзакцию.

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

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

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

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

2
задан 20 April 2017 в 21:47
3 ответа

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

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

0
ответ дан 3 December 2019 в 14:11

Я не думаю, что смогу ответить на ваш вопрос напрямую, учитывая отсутствие у меня доступа к вашим системам и предоставленной информации. Однако вот несколько УДИВИТЕЛЬНЫХ инструментов, которые я использовал, чтобы лучше справиться со всеми разновидностями баз данных, производных от 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 ...)

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

The Percona Toolkit (ранее MAATKIT): https://www.percona.com/software/database-tools/percona-toolkit

Удачи!

1
ответ дан 3 December 2019 в 14:11

Чем заняться в [ 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
-1
ответ дан 3 December 2019 в 14:11

Теги

Похожие вопросы