Человеческий мозг обычно лучше воспринимает информацию из изображений, чем из текстов. И в инструментах, подобных Flame Graph, этот принцип блестяще реализован. Поэтому в Percona его используют в рамках работы группы поддержки. Чаще всего в тех случаях, когда нужно получить всестороннее представление о том, что и как долго проделывает MySQL. Так можно лучше понять, какие операции стоят за конкретной рабочей нагрузкой и каким образом лучше исправлять возникающие проблемы. И это можно использовать и для оптимизации, и для устранения неполадок.

Давайте воспользуемся их опытом и разберемся, откуда брать и как подготавливать образцы для визуализации данных. А после этого — как из них генерировать Flame Graph и как с этим работать.

Сегодня SQL используют уже буквально все на свете: и аналитики, и программисты, и тестировщики, и т.д. Отчасти это связано с тем, что базовые возможности этого языка легко освоить. 

Однако работая с большим количеством junior-ов, мы раз от раза находим в их решениях одни и те же ошибки. Реально — иногда просто создается ощущение, что они копируют друг у друга код. 

Кстати, иногда такая же участь постигает и специалистов более высокого полета. 

Сегодня мы решили собрать 7 таких ошибок в одном месте, чтобы как можно меньше людей их совершали.

Развитие происходит по спирали: когда-то люди не умели правильно индексировать, потом (в основном) научились, потом пришли noSQL и все снова забыли знание древних. Что вы будете делать, когда последние из старых DBA отплывут в Валинор?

Снова и снова и сталкиваюсь с полным набором антипаттернов индексирования. Я их перечислю, но! Для каждого антипаттерна есть исключение, когда именно это и стоит делать. Поэтому кликбейтно сформулированное правило верно в 95% случаях, но если вы хотите копнуть глубже, то прочитайте про исключения.

И в конце полезные скрипты для MSSQL, Postgres и MySQL.

Настроить репликацию в MySQL просто, но управление ею в продакшне никогда не было легкой задачей. Даже с новым автоматическим позиционированием GTID все может пойти не так, если не знать, что делать. После настройки репликации может произойти всякое. Легко допустить ошибки, которые приведут к катастрофическим последствиям для ваших данных.

В этой статье мы рассмотрим некоторые из наиболее распространенных ошибок, допускаемых при репликации MySQL, и то, как их можно предотвратить.

Говорят, что вакцины стали жертвами собственной эффективности. Будто если бы мы видели, как странновато одетый кучер раз в неделю забирал бы трупы нескольких соседей, умерших, как и десятки до них, довольно неприятной смертью, может, и вакцинировались бы охотнее.

Я не ученый вирусолог/эпидемиолог/фармацевт, я зарабатываю себе не хлеб тем, что пишу программы. Иногда мне кажется, что делаю это довольно успешно. Сегодня в очередной раз я услышал фразу, что привел в эпиграфе, а вчера в баре под укоризненные взгляды друзей рассказывал, как я отбился в проекте от использования какой-то нереляционки и у меня в голове щелкнуло и я сел набирать этот текст.

С середины прошлого века мы работаем над реляционными базами данных. И они прекрасны. Но сейчас все чаще любят использовать NoSQL всех видов и мастей. И они иногда неплохо ложатся и затыкают собой какое-то мелкое место в проекте. Если я ценю свои данные и мне нужна какая-то надежность, то мне нужны ACID гарантии. Если это всего лишь кеш, данные из которого нужны чтобы ускорить приложение то я с радостью возьму Redis или аналоги. Ведь если он упадет или данные рассогласуются я смогу их восстановить из нормальной базы.

Рано или поздно любой разработчик или администратор СУБД, имеющий дело с MySQL, сталкивается с проблемой блокировок. Всё дело в природе MySQL как системы с конкурентным доступом на чтение/запись. Я расскажу о видах блокировок в MySQL, их преимуществах и недостатках, о проблемах, которые они вызывают, а также дам полезные советы по обнаружению и способам борьбы с блокировками.

Зачем я это читаю?

TL;DR:

• Переложив секции кода и данных программы на большие страницы можно существенно ускорить приложение (у нас получилось до +10%) не трогая исходный код.
• Можно быстро проверить ничего не перекомпилируя, детали здесь.
• Финальное решение оперирует "классическими" большими страницами (не transparent huge pages), поэтому в какой-то степени его можно назвать дальнейшим развитием 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.

В статье расскажем, почему решили его написать и расскажем, что он умеет.

Как создать Viber чат-бота на Python для диспетчеризации технологического процесса.

Технологические гиганты при помощи денег инвестиционных фондов контролируют всё большую часть новых разработчиков и продуктов, перекрывая тем самым путь для новых программ и новых технологий в строительной отрасли. 

Сегодняшние лидеры САПР-индустрии: 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 максимально подробно.