Комментарии 18
Слова слова, а толку никакого. Этих слов, что нужно собирать для MySQL, что нужно мониторить вылито на просторы рунета тоннами. И все равно все хотят лить и лить эту воду. Смысл в этих изливаниях?
Самое правильно, ИМХО — это выложить свой шаблон для Zabbix или дашборд Prometheus и сказать — вот, мы используем это и это работает, это проверено на проде, это проверено при разборе инцидентов, все нужное тут есть.
Но нет же, опять льем воду.
Да, вы сейчас скажите, что стандартные шаблоны Zabbix или дашборд Prometheus с какого то там репа на гитхабе все показывает, но давайте скажем честно, что везде есть баги и каждый пилит что-то свое на основе общедоступного.
Самое правильно, ИМХО — это выложить свой шаблон для Zabbix или дашборд Prometheus и сказать — вот, мы используем это и это работает, это проверено на проде, это проверено при разборе инцидентов, все нужное тут есть.
Но нет же, опять льем воду.
Да, вы сейчас скажите, что стандартные шаблоны Zabbix или дашборд Prometheus с какого то там репа на гитхабе все показывает, но давайте скажем честно, что везде есть баги и каждый пилит что-то свое на основе общедоступного.
Поддерживаю, воды в статье действительно много.
Вы говорите о технической стороне вопроса. Она безусловно важна, но в 2021-ом году как Вы справедливо и заметили источников на тему «как сделать самый лучший мониторинг MySQL, PostgreSQL, Kafka, Cassandra, Nginx, you name it» очень много, но эффективность и стабильность сегодняшнего прода определяют прежде всего процессы и коммуникации, а их из Интернета не скачаешь. Статья как раз об этом.
Использую официальный темплейт mysql для zabbix-agent2 — работает «из коробки»
mysql в финансах я бы не рискнул. у mysql мягко говоря странноватый подход к блокировкам, при full scan блокировки накладываются на все что вычитывает запрос, а не то что требуется заблокировать.
Если у Вас запрос сканирует всю таблицу, то начинать нужно не с блокировок, а с оптимизации этого самого запроса.
с чего бы это? в нормальных субд, например, оракл в принципе если запрос затрагивает более 25% строк — таблица full scan достается. но это не повод же блокировать всю таблицу.
а у mysql получается, что с дедлогами могут запросто завалится даже INSERT INTO… SELECT
а у mysql получается, что с дедлогами могут запросто завалится даже INSERT INTO… SELECT
Спасибо за шикарный пример!
Вот так обычно и оказывается, что и бабушка не бабушка, а немножко дедушка, и SELECT не просто SELECT, а INSERT INTO… SELECT FROM, да еще целой таблицы. А это уже транзакция с записью. И никакая транзакционная БД вам за такое спасибо не скажет. И даже в этом случае таблица-источник в InnoDB не блокируются. Если так уж необходимо переливать всю таблицу — разбейте эту операцию на блоки по 3-5 тысяч строк, а лучше отрефакторите приложение. Админы и пользователи скажут Вам спасибо.
Вот так обычно и оказывается, что и бабушка не бабушка, а немножко дедушка, и SELECT не просто SELECT, а INSERT INTO… SELECT FROM, да еще целой таблицы. А это уже транзакция с записью. И никакая транзакционная БД вам за такое спасибо не скажет. И даже в этом случае таблица-источник в InnoDB не блокируются. Если так уж необходимо переливать всю таблицу — разбейте эту операцию на блоки по 3-5 тысяч строк, а лучше отрефакторите приложение. Админы и пользователи скажут Вам спасибо.
чувак, я не говорил про селект, я говорил про full scan.
Хорошо, допустим. Теперь вопрос: как и зачем в проде появляется запрос на изменение данных который делает full scan? Может быть есть смысл построить индекс и читать только те строки, которые обновляются? Или обновлять значения по первичному ключу?
Когда-то давно на sql.ru постили песенку Ослика-ораклиста. Прошло много лет, но актуальности она не потеряла
Hе секрет, что rollback надо делать пореже,
Лучше делать почаще commit!
Я программой своей скоро сервер повешу -
У админа пускай голова поболит.
Под крики о кастрации,
В обкуренной прострации,
Как следствие мутации
Рождается в момент
Rollback segment для маленькой,
Для маленькой такой транзакции,
Для скромной такой транзакции
Огромный такой сегмент!
Hе секрет, что rollback - это язва и грыжа,
Геморрой и чуть-чуть гайморит.
Если ты программист, а не ослик бесстыжий -
Лучше делай почаще commit!
Припев.
Hе секрет, что друзьям тоже надо ресурсы,
Hадо память, процессор и диск...
Так что делай commit, а иначе... ты в курсе,
Что rollback - для тебя неоправданный риск.
Кроме того, MySQL при чтении сами строки не блокирует, если конечно не указать FOR UPDATE. Блокируются только метаданные (структура таблицы).
ну так кроме SELECT с FOR UPDATE могут быть UPDATE, DELETE, INSERT INTO… SELECT.
пример с DELETE тут
dba.stackexchange.com/questions/238756/mysql-innodb-trying-to-lock-uncommitted-row-from-parallel-transaction-deadlock
пример с DELETE тут
dba.stackexchange.com/questions/238756/mysql-innodb-trying-to-lock-uncommitted-row-from-parallel-transaction-deadlock
MySQL, как и любая ACID-complaint база вынуждена блокировать изменяемые строки, что бы не допустить ситуации, когда одна и так же строка будет поменяна в двух параллельных транзакциях. Такой подход гарантирует целостность данных, например то, что стоимость покупки в магазине не будет списана с Вашего счета дважды. Если Вам не нужна целостность данных — Вам не нужна транзакционность и связанные с ней накладные расходы (блокировки это только один пункт из большого списка). В целом Вам не нужна ACID база. Берите что-то по-проще и будет Вас счастье.
это ложь. никто mysql не вынуждает блокировать больше строк, чем указано в предикате запроса. оракл при full scan считывает страницу данных с диска/кеша накладывая latch и блокирует на этой странице лишь те строки, какие будут модифицированы.
открой ссылку и посмотри пример c mysql, параллельные транзакции никак не пересекаются, никакой необходимости их блокировать нет. каждая создает свой набор строк и свой же набор пытаются удалить. у нормальной субд в такой ситуации не будет дедлока.
открой ссылку и посмотри пример c mysql, параллельные транзакции никак не пересекаются, никакой необходимости их блокировать нет. каждая создает свой набор строк и свой же набор пытаются удалить. у нормальной субд в такой ситуации не будет дедлока.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MySQL в финансах: реакция или созидание?