Галера кластер из двух нод + арбитратор marriadb 10.5.13/ В логе БД появляются записи: May 29 05:51:44 hostname mariadbd: 2023-05-29 5:51:44 6554176 [Warning] Aborted connection 6554176 to db: 'db_name' user: 'user_name' host: 'host_ip' (init_connect command failed)
May 29 05:51:44 hostname mariadbd: 2023-05-29 5:51:44 6554176 [Warning] Deadlock found when trying to get lock; try restarting transaction/ И таких записей много, критично, если записей подряд 7(т.к балансировщик в таком случае удаляет виртуальный ip)/ В innodb status информации о дедлоках нет, в системном логе так же, хотя print_deadlock=1/ на стороне приложения так же нет ничего о дедлоках. Может кто сталкивался с таким? Приложение в кубере. Когда на ВМ было и на версии mariadb старше, проблем не фиксировал. Много написал, просьба помочь разобраться.
Раньше проблем быть не могло, потому что медленнее работало в целом, например. Если записей про deadlock нет, то это, наверное, галеровские дедлоки. Нужно включить опцию https://galeracluster.com/library/documentation/mysql-wsrep-options.html#wsrep-log-conflicts или даже https://galeracluster.com/library/documentation/mysql-wsrep-options.html#wsrep-debug
у галеры есть так же дедлоки? я не знал об этом
Если примитивно объяснять как работает Галера, то она копирует изменение с одной ноды на другие. Так как там тоже есть транзакции, то могут возникать конфликты, в том числе дедлоки. Именно поэтому рекомендуют писать только на одной ноде, хотя технически возможно писать на всех сразу.
Добрый день. Запись идет только на одну ноду галеры. Поэтому я не понимаю, как могут возникать дедлоки.
А точно на одну ноду? Кубер не может нагрузку перераспределять?
точно, приложение обращается к БД по виртуальному ip, который находиться только на одной из нод галеры
А остальных нод select @@global.read_only; select @@global.super_read_only; 1 возвращает? 😊 или это все же "на честном слове"?
Обсуждают сегодня