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