go-приложение. Если между го-приложением и базой появляются сетевые проблемы, база облипает локами, кратно вырастают коннекты от Go, и ей становится прям не очень. Понятно, что будем стараться не допускать сетевых проблем. Но на стороне mysql можно как-то от этого подстраховаться?
Выкрутить таймауты
вот тоже про них думаю. а какие? всякие net_read_timeout net_write_timeout ?
It depends Если у вас локи возникают из-за незавершенных транзакций, то можно закрутить kill_idle_transaction
А, еще нюанс - kill_idle_transaction это только в перконовском форке есть
использовал эту опцию когда-нибудь? если да, то сколько?
Постоянно. Конкретные значения зависят от профиля нагрузки, если у вас короткие, недолго живущие транзакции, то смело можно выкручивать в 10 секунд. Но по хорошему надо собирать слоу лог и анализировать его на этот предмет
А если кешировать треды ? Max scale/proxysql и тд ?
@xatrixtm, судя по https://docs.percona.com/percona-server/5.7/management/innodb_kill_idle_trx.html#kill_idle_transaction транзакция будет грохнута просто из-за того, что она "простаивает"? Независимо от причины почему простаивает? Вдруг блокировку какую ждёт или такого не ожидается?
Ожидание лока это не idle, в этом случае статус коннекта будет совсем другой и там будут действовать совсем другие таймауты
ну, если по другому - кроме как сетевая задержка - какие еще могут быть причины для тех тормозов, вследствии которых транзакция будет убита (если еще могут быть какие-то причины)? Раз не локи.
Например человеческий фактор. Кто-то начал транзакцию, сделал например делит, а потом отвлекся на обед. А транзакция висит, ждет. Или скрипт, который работает с несколькими базами, открыл транзакцию, сделал батч инсерт и ждет ответа от другой базы для следующей порции данных. В этом случае она тоже будет убита если время ожидания будет превышено
Звучит логично.. Только заранее подготовиться к атаке со стороны разработчиков 😊 - что за дела, я открыл транзакцию, ушел курить, возвращаюсь, а она убита.
Это действительно может подложить проблем, когда этот курильщик бахнет следующий запрос, не посмотрев что транзакция была убита. Но тут я могу только посоветовать убирать доступ на прод)
оно через proxysql идёт
ага, курильщикам и обжорам 😊)). Ну, я помню на уменьшение wait_timeout сперва тоже ворчали, потом объяснил, кулачком по столу постучал - угомонились.
Рекомендую еще тогда взглянуть на max_execution_time. Раз уж взялись гайки закручивать)
дать им отдельного юзера и поставить лимит коннектов
о, я и не знал, что в мускуле завезли лимит пер юзер
Обсуждают сегодня