Рано или поздно любой разработчик или администратор СУБД, имеющий дело с MySQL, сталкивается с проблемой блокировок. Всё дело в природе MySQL как системы с конкурентным доступом на чтение/запись. Я расскажу о видах блокировок в MySQL, их преимуществах и недостатках, о проблемах, которые они вызывают, а также дам полезные советы по обнаружению и способам борьбы с блокировками.
TL;DR:
libhugetlbfs.
Каждый день мы пишем код в условиях высоких нагрузок, и нередко в таких случаях сталкиваемся с проблемами, связанными с базой данных. Мы в компании используем MySQL, поэтому я расскажу про конфигурирование соединений с этой базой данных. Пройдемся по основным моментам, на которые нужно обращать внимание при работе с MySQL средствами языка Go:
• немного затронем основы клиент-серверного протокола MySQL, его базовое устройство и принципы работы;
• дальше перейдем к Go части и разберем реализацию пула соединений;
• будем двигаться от конфигурирования соединений к выполнению запросов, параллельно заглядывая в код драйвера.
Надеюсь каждый для себя найдет что-то полезное.
В среднем 24,1 ответа в день (если все 365 дней в году считать рабочими) на протяжении почти 10 лет.
Несколько дней назад на некоторых англоязычных ресурсах началось обсуждение одного очень необычного пользователя Stack Overflow. Его зовут Гордон Линофф (Gordon Linoff), он из Нью-Йорка, и за 9 лет и 8 месяцев своего присутствия на платформе он дал 85,201 ответов на различные вопросы, в основном связанные с SQL и дата-майнингом (цифра актуальна на 27.09.2021).
Что это за маг?
Прим. перев.: в процессе поиска решения проблемы с логированием медленных запросов MySQL наткнулся на довольно познавательную статью. Её автор не только в деталях описывает своё расследование, которое может оказаться полезным для начинающих администраторов, но и попутно пробуждает чувства ностальгии по эпохе VT100.
Сначала краткая предыстория. Я пытался сделать так, чтобы логи медленных запросов в MySQL писались в /dev/stderr и их можно было бы читать с помощью простого docker-compose logs -f mysql без необходимости входить в контейнер с docker-compose exec mysql ash.
Мы в KTS на многих проектах пользуемся услугами managed database от selectel. За этими кластерами нужно следить, и делать это хотелось бы из одной точки. Этой точкой у нас является prometheus, alertmanager и grafana.
Из коробки у selectel нет prometheus exporter для manage-баз данных. Есть внутренние графики и мониторинг, но использовать их затруднительно. Поэтому мы написали свой selectel-exporter, который использует selectel API.
В статье расскажем, почему решили его написать и расскажем, что он умеет.
Технологические гиганты при помощи денег инвестиционных фондов контролируют всё большую часть новых разработчиков и продуктов, перекрывая тем самым путь для новых программ и новых технологий в строительной отрасли.
Сегодняшние лидеры САПР-индустрии: Autodesk, Hexagon, Nemetschek, Bentley, Trimble - хорошо готовятся к будущим угрозам: стандартной тактикой больших корпораций стал агрессивный захват новых рынков и поглощение возможных конкурентов на ранних стадиях развития.
В результате вся САПР-индустрия стала похожа на олигополию, в которой доминирует группа из нескольких компаний. И их положение на вершине становится всё более непоколебимым.
Алексей Миловидов делает ClickHouse и, конечно, знает его вдоль и поперек. В том числе и о том, как его можно использовать дополнительно к его штатным и всем хорошо известным функциям.
И сегодня расскажет про эти необычные способы его использования и, может быть, даже не для хранения и обработки данных.
Прим. перев.: в этой статье сербский «инженер по масштабируемости» нагруженного онлайн-проекта в подробностях рассказывает о своем опыте оптимизации большой БД на базе MySQL. Проведена она была для того, чтобы выдержать резкий рост трафика на сайт, случившийся из-за пандемии.
База данных становится слишком большой или старой? Ее тяжело обслуживать? Что ж, надеюсь, я смогу немного помочь. Текст, который вы собираетесь прочитать, содержит реальный опыт масштабирования монолитной базы данных, лежащей в основе одного из сайтов Топ-250 (согласно alexa.com). На момент написания этой статьи chess.com занимал 215 место в мире по популярности. Ежедневно к нам заглядывали более 4 млн уникальных пользователей, а наши MySQL-базы обрабатывали в общей сложности более 7 млрд запросов. Год назад сайт ежедневно посещали 1 млн уникальных пользователей; в марте прошлого года их число увеличилось до 1,3 млн; сегодня более 4 млн человек заходят на chess.com ежедневно, а число сыгранных партий превышает 8 млн. Я, конечно, знаю, что это не сопоставимо с самыми крупными игроками на рынке, однако наш опыт все же может помочь в такой сложной задаче, как «исправление» монолитной базы данных и ее вывод на новый уровень производительности.
Высоконагруженные приложения финансовой сферы предъявляют жесткие требования ко всем компонентам, особенно к системе хранения данных.
Нужно постоянно и стабильно держать нагрузку, несмотря, а иногда и вопреки отказам, поломкам и внезапным миграциям. О том, как приходится жить DBA в мире стремительного повышения нагрузок и высоких требованиях стабильности, в своем докладе на конференции Saint HighLoad++ Online 2020 рассказал эксперт по базам данных ECOMMPAY IT Владимир Федорков.
Многим, кто работает с MySQL, известно, что команда EXPLAIN используется для оптимизации запросов, получения информации об использованных и возможных индексах. Большинство разработчиков и администраторов СУБД этой информацией и ограничивается. Я же предлагаю изучить команду EXPLAIN максимально подробно.
Эта статья не является ответом на множество вопросов по базам данных (БД) и системам управлениям базами данных (СУБД). Я как автор выражаю своё собственное мнение о трендах, стараясь опираться на беспристрастные показатели, статистики и т.д., но для примера приводя собственный опыт. Я не являюсь ангажированным представителем какой-либо компании и выражаю точку зрения опираясь на опыт более 25 лет работы с разными СУБД, в том числе, которую создавал своими руками. Не так много даже опытных программистов и архитекторов, которые знают все термины, технологии, какие подводные камни и куда идёт движение. Тема поистине огромная, поэтому в рамках одной статьи не раскрыть даже верхний уровень информации. Если кто-то не встретит свою любимую СУБД или её невероятный плюс, который стоит упомянуть, то прошу в комментариях указать и этим дополнить общую картину, что поможет другим разобраться и понять лучше предметную область. Поехали!
Open Source DBMS vs Commercial DBMS
Для начала приведён график с сайта, db-engines.com, по моим ощущениям, неплохо отслеживающим тренды БД. Именно этот график добавил желания написать статью о текущем положении дел.
Приглашаем на мастер-классы «Тюнинг и масштабирование проекта на MySQL» 15—17 декабря 2020. Расскажем, что именно настроить, чтобы база не тормозила и не падала, а данные не терялись. Поможем найти медленные запросы и сделать их быстрыми.
Мастер-классы ведет Владимир Федорков, специалист по настройке и эксплуатации СУБД MySQL, эксперт в сфере производительности MySQL, постоянный спикер конференций в России, Европе и США.
MySqlException: Incorrect TIME value: '960:00:00.000000'40:00:00:00 будет представлять 40 дней. Но действительность оказалась куда сложнее и запутаннее.
Понимание того, как MySQL использует память, является ключом к настройке системы для достижения оптимальной производительности, также как и для устранения неполадок в случаях ненормального использования памяти, например, когда у вас есть сервер MySQL, использующий намного больше памяти, чем вы ожидаете, исходя из параметров конфигурации.
На заре MySQL понимание всех тонкостей и нюансов использования памяти было трудным и включало очень много догадок. Быть может, для выполнения некоторых запросов требуется большая временная таблица или выделение больших объемов памяти для сохраненных пользовательских переменных? Может, какие-либо хранимые процедуры занимают неожиданно большой объем памяти? Причиной чрезмерного использования памяти MySQL могло оказаться что угодно, но у вас не было легких путей понять и быть уверенным, что именно.
Все это изменилось в MySQL 5.7, который добавил инструментарий для отслеживания памяти в Performance Schema, а в MySQL 8.0 этот инструментарий стал включен по умолчанию, поэтому вы можете получить эти данные практически с любого работающего инстанса.