Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
Что нужно знать о трёх топовых фичах MySQLSveta Smirnova
MySQL прочно удерживает второе по популярности место после Oracle в рейтинге DB-engines: https://db-engines.com/en/ranking_trend Репликация, табличные движки и поддержка NoSQL не дают MySQL сдавать позиции с 2012 года: года основания рейтинга. Что особенного в этих фичах? Что нужно знать, чтобы использовать их на полную мощность?
Я расскажу про дизайн. Именно он отвечает за то, чтобы ваше приложение не достигло потолка производительности. Понимание архитектуры поможет при проектирование нового приложения, которое впоследствии будет легко масштабироваться.
Доклад рассчитан для начинающих пользователей MySQL. Однако поможет освежить свои знания и более опытным.
Talk for the DevOps Pro Moscow 2021: https://www.devopspro.ru/Sveta-Smirnova/
Производительность MySQL можно улучшить при помощи оптимизации запросов, настроек MySQL сервера и железа. Традиционно эти задачи распределялись между тремя ролями: Разработчик, Администратор баз данных и Системный Администратор. Теперь же все эти задачи решает DevOps, что непросто для одного человека. В этом докладе я расскажу об основных оптимизациях, которые решают большинство проблем производительности MySQL. Для иллюстраций я буду использовать реальные пользовательские истории и Percona Kubernetes Operator.
Современному хайлоду - современные решения: MySQL 8.0 и улучшения PerconaSveta Smirnova
MySQL всегда использовали под высокой нагрузкой. Недаром эта база была и остаётся самым популярным бэкэндом для web. Однако наши представления о хайлоде с каждым годом расширяются. Большая скорость передачи данных -> больше устройств с подключением к интернет -> больше пользователей -> больше данных.
Задачи, стоящие перед разработчиками MySQL, с каждым годом усложняются.
В этом докладе я расскажу как менялись сценарии использования MySQL за [почти] 25 лет её истории и что делали инженеры, чтобы MySQL оставалась актуальной. Мы затронем такие темы, как работа с большим количеством активных соединений и высокими объёмами данных. Я покажу насколько современные версии лучше справляются с возросшими нагрузками.
Я надеюсь, что после моего доклада те слушатели, которые используют старые версии, захотят обновиться и те, кто уже обновились, узнают как использовать современный MySQL на полную мощность.
Прочитана на конференции OST 2020: https://ostconf.com/materials/2857#2857
Оптимизация UI потока / Дмитрий Куркин (Mail.Ru)Ontico
- WatchDog. Что это такое? Схема реализации с таймером и схема реализации на RunLoop'e.
- Как собирать результат работы WatchDog. Примеры того, что можно таким образом найти, и что мы нашли на проекте ICQ.
- Как работать с полученными результатами. Анализ стеков потоков. Профилирование с учетом расходов на синхронизацию.
- Проблемы при работе с WatchDog. Системные механизмы и популярные библиотеки, вызывающие проблемы. Методы обхода этих проблем. Итоговые параметры, применяемые на проекте ICQ.
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
Что нужно знать о трёх топовых фичах MySQLSveta Smirnova
MySQL прочно удерживает второе по популярности место после Oracle в рейтинге DB-engines: https://db-engines.com/en/ranking_trend Репликация, табличные движки и поддержка NoSQL не дают MySQL сдавать позиции с 2012 года: года основания рейтинга. Что особенного в этих фичах? Что нужно знать, чтобы использовать их на полную мощность?
Я расскажу про дизайн. Именно он отвечает за то, чтобы ваше приложение не достигло потолка производительности. Понимание архитектуры поможет при проектирование нового приложения, которое впоследствии будет легко масштабироваться.
Доклад рассчитан для начинающих пользователей MySQL. Однако поможет освежить свои знания и более опытным.
Talk for the DevOps Pro Moscow 2021: https://www.devopspro.ru/Sveta-Smirnova/
Производительность MySQL можно улучшить при помощи оптимизации запросов, настроек MySQL сервера и железа. Традиционно эти задачи распределялись между тремя ролями: Разработчик, Администратор баз данных и Системный Администратор. Теперь же все эти задачи решает DevOps, что непросто для одного человека. В этом докладе я расскажу об основных оптимизациях, которые решают большинство проблем производительности MySQL. Для иллюстраций я буду использовать реальные пользовательские истории и Percona Kubernetes Operator.
Современному хайлоду - современные решения: MySQL 8.0 и улучшения PerconaSveta Smirnova
MySQL всегда использовали под высокой нагрузкой. Недаром эта база была и остаётся самым популярным бэкэндом для web. Однако наши представления о хайлоде с каждым годом расширяются. Большая скорость передачи данных -> больше устройств с подключением к интернет -> больше пользователей -> больше данных.
Задачи, стоящие перед разработчиками MySQL, с каждым годом усложняются.
В этом докладе я расскажу как менялись сценарии использования MySQL за [почти] 25 лет её истории и что делали инженеры, чтобы MySQL оставалась актуальной. Мы затронем такие темы, как работа с большим количеством активных соединений и высокими объёмами данных. Я покажу насколько современные версии лучше справляются с возросшими нагрузками.
Я надеюсь, что после моего доклада те слушатели, которые используют старые версии, захотят обновиться и те, кто уже обновились, узнают как использовать современный MySQL на полную мощность.
Прочитана на конференции OST 2020: https://ostconf.com/materials/2857#2857
Оптимизация UI потока / Дмитрий Куркин (Mail.Ru)Ontico
- WatchDog. Что это такое? Схема реализации с таймером и схема реализации на RunLoop'e.
- Как собирать результат работы WatchDog. Примеры того, что можно таким образом найти, и что мы нашли на проекте ICQ.
- Как работать с полученными результатами. Анализ стеков потоков. Профилирование с учетом расходов на синхронизацию.
- Проблемы при работе с WatchDog. Системные механизмы и популярные библиотеки, вызывающие проблемы. Методы обхода этих проблем. Итоговые параметры, применяемые на проекте ICQ.
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)Ontico
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)Ontico
В MySQL 5.7 появился целый ряд новых возможностей, позволяющих использовать MySQL в приложениях и как хранилище JSON-документов, и как реляционную базу данных.
В этом докладе мы расскажем о поддержке JSON в MySQL 5.7, а также поговорим о том, когда имеет смысл её использовать, и насколько хорошо она работает. Кроме того, мы остановимся на новом протоколе доступа к MySQL, поддерживающем SQL. Помимо этого, мы рассмотрим CRUD-операции и такие дополнительные функции, как асинхронная коммуникация и пайплайнинг (pipelining).
В заключительной части доклада мы расскажем о возможностях MySQL 5.7 в качестве хранилища документов.
Что нового в nginx? / Максим Дунин (Nginx, Inc.)Ontico
Что нового появилось в nginx за последнее время и для чего всё это нужно?
В докладе - рассказ про основные новые функции в nginx 1.9.x (1.10.x) и 1.11.x. HTTP/2, модуль stream, динамическая загрузка модулей и так далее - зачем всё это нужно и как это использовать.
Читаем CHANGES вместе и разбираем на примерах.
Deployment to production with an unexpected loadGrid Dynamics
In his talk, Max Mazur a DevOps Engineer at Grid Dynamics, shares his experience deploying to production despite unexpected loads using the example of the web application (RTB). There you can find specific cases of using MySQL and resolving solutions. Technology stack: Linux, MySQL, PHP, Nginx, Kafka, Redis, Gearman
Эффективная отладка репликации MySQL / Света Смирнова (Percona)Ontico
Репликация - одна из ключевых возможностей MySQL. Лёгкая в установке, позволяющая производить изменения и на мастере, и на слейве, что в свою очередь позволяет создавать сколь угодно сложные развёртывания. Репликация в MySQL асимметричная, допускающая некоторый уровень синхронизации при помощи semi-sync replication plugin. Начиная с версии 5.7 поддерживает одновременную репликацию с нескольких мастеров на один слейв.
Простота использования имеет свою обратную сторону: при проектировании репликации достаточно легко выбрать неправильное решение и познакомиться со всеми его подводными камнями.
В рамках этого доклада я расскажу об особенностях репликации MySQL, типичных ошибках и способах борьбы с ними. Мы затронем как проблемы, приводящие к появлению неожиданных данных и десинхронизации, так и производительность.
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
Zabbix 3.4 - простая непростая дружба с сообществом / Алексей Владышев (Zabbix)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 14:00
Тезисы:
http://rootconf.ru/2017/abstracts/2708.html
Сообщество любого открытого проекта созидательно по сути, не использовать эту силу будет большой ошибкой. Но всегда ли нужно слепо следовать за мнением большинства?
В своём докладе я расскажу о новой функциональности, ожидаемой в версии Zabbix 3.4, какие запросы наших пользователей мы решили реализовать, и какую роль в формировании роадмапа играет сообщество. Затрону тему общих принципов формирования роадмапа, и почему мы не готовы работать над всеми хотелками сообщества. Некоторые из них приходится ждать годами, а некоторые мы реализуем буквально за день.
Я расскажу о том, как мы работаем с сообществом, мониторим и реализуем запросы. Всегда ли мы это делаем эффективно или что-то можно улучшить?
Приходите! Доклад будет интересен не только тем, кто интересуется Zabbix и мониторингом в целом, но, надеюсь, что и разработчикам открытых программных продуктов.
Очереди и блокировки. Теория и практика / Александр Календарев (ad1.ru)Ontico
В докладе будут описаны паттерны использования очередей и блокировок, рассказано, зачем нужны очереди и блокировки, показано на примерах использования в разных архитектурах.
Описано применение синхронных и асинхронных очередей, как построить очереди с приоритетами.
Будет сравнение разных серверов очередей: Redis, Tarantool, RabbitMQ, ZMQ, Kafka, Zookeeper, MemcacheQ и др., их преимущества и недостатки, где и какой брокер лучше использовать.
Девять кругов ада или PostgreSQL Vacuum / Алексей Лесовский (PostgreSQL-Consu...Ontico
Если вы сталкивались с PostgreSQL и зашли дальше, чем инструкция по установке, то, скорей всего, коротко познакомились с вакуумом, ну или, как минимум, что-то слышали про него.
Вакуум или по-русски очистка - это важная задача в жизненном цикле постгреса, которая заключается в регулярном освобождении базы данных от, так скажем, "мусора". Вакуум очень важен, его нельзя игнорировать и тем более отключать; более того, ему следует уделять должное внимание. А за кажущейся простотой скрывается довольно сложный и интересный механизм, к работе которого очень часто возникает много вопросов, на которые не всегда можно найти однозначный ответ.
В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
"OpenStack & Oracle — взболтать, но не смешивать". Сергей Филимонцев, ЯндексYandex
Все enterprise-решения имеют свою специфику и отличаются весьма щепетильным подходом к эксплуатации. Но иногда возникает необходимость тиражировать их с минимальными усилиями. Нам в Яндексе понадобилось создать множество тестовых сред с продуктами Oracle. Для облегчения этой задачи мы виртуализовали их в приватном облаке OpenStack. В докладе пойдёт речь об этом опыте: с какими проблемами пришлось столкнуться и как мы будем использовать в дальнейшем полученные знания.
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
How to build solid CI-CD pipeline / Илья Беда (beda.software)Ontico
РИТ++ 2017, Root Conf
Зал Конгресс-холл, 6 июня, 15:00
Тезисы:
http://rootconf.ru/2017/abstracts/2551.html
На основе своего опыта работы в консалтинге я расскажу, как избавить разработчиков от рутинных задач и как сэкономить на ресурсах команды с помощью правильно настроенного CI-CD pipeline.
Единствено верный способ упаковки приложений - это Docker-контейнеры, благодаря этому способу вы сможете унифицировать процесс деплоя. Нужно деплоить приложения с помощью Ansible-плейбука, запакованного в Docker-контейнер, это снижает требования к окружению CI-ранера. Вам нужен только Docker.
...
We all have tasks from time to time for bulk-loading external data into MySQL. What's the best way of doing this? That's the task I faced recently when I was asked to help benchmark a multi-terrabyte database. We had to find the most efficient method to reload test data repeatedly without taking days to do it each time. In my presentation, I'll show you several alternative methods for bulk data loading, and describe the practical steps to use them efficiently. I'll cover SQL scripts, the mysqlimport tool, MySQL Workbench import, the CSV storage engine, and the Memcached API. I'll also give MySQL tuning tips for data loading, and how to use multi-threaded clients.
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)Ontico
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)Ontico
В MySQL 5.7 появился целый ряд новых возможностей, позволяющих использовать MySQL в приложениях и как хранилище JSON-документов, и как реляционную базу данных.
В этом докладе мы расскажем о поддержке JSON в MySQL 5.7, а также поговорим о том, когда имеет смысл её использовать, и насколько хорошо она работает. Кроме того, мы остановимся на новом протоколе доступа к MySQL, поддерживающем SQL. Помимо этого, мы рассмотрим CRUD-операции и такие дополнительные функции, как асинхронная коммуникация и пайплайнинг (pipelining).
В заключительной части доклада мы расскажем о возможностях MySQL 5.7 в качестве хранилища документов.
Что нового в nginx? / Максим Дунин (Nginx, Inc.)Ontico
Что нового появилось в nginx за последнее время и для чего всё это нужно?
В докладе - рассказ про основные новые функции в nginx 1.9.x (1.10.x) и 1.11.x. HTTP/2, модуль stream, динамическая загрузка модулей и так далее - зачем всё это нужно и как это использовать.
Читаем CHANGES вместе и разбираем на примерах.
Deployment to production with an unexpected loadGrid Dynamics
In his talk, Max Mazur a DevOps Engineer at Grid Dynamics, shares his experience deploying to production despite unexpected loads using the example of the web application (RTB). There you can find specific cases of using MySQL and resolving solutions. Technology stack: Linux, MySQL, PHP, Nginx, Kafka, Redis, Gearman
Эффективная отладка репликации MySQL / Света Смирнова (Percona)Ontico
Репликация - одна из ключевых возможностей MySQL. Лёгкая в установке, позволяющая производить изменения и на мастере, и на слейве, что в свою очередь позволяет создавать сколь угодно сложные развёртывания. Репликация в MySQL асимметричная, допускающая некоторый уровень синхронизации при помощи semi-sync replication plugin. Начиная с версии 5.7 поддерживает одновременную репликацию с нескольких мастеров на один слейв.
Простота использования имеет свою обратную сторону: при проектировании репликации достаточно легко выбрать неправильное решение и познакомиться со всеми его подводными камнями.
В рамках этого доклада я расскажу об особенностях репликации MySQL, типичных ошибках и способах борьбы с ними. Мы затронем как проблемы, приводящие к появлению неожиданных данных и десинхронизации, так и производительность.
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
Zabbix 3.4 - простая непростая дружба с сообществом / Алексей Владышев (Zabbix)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 14:00
Тезисы:
http://rootconf.ru/2017/abstracts/2708.html
Сообщество любого открытого проекта созидательно по сути, не использовать эту силу будет большой ошибкой. Но всегда ли нужно слепо следовать за мнением большинства?
В своём докладе я расскажу о новой функциональности, ожидаемой в версии Zabbix 3.4, какие запросы наших пользователей мы решили реализовать, и какую роль в формировании роадмапа играет сообщество. Затрону тему общих принципов формирования роадмапа, и почему мы не готовы работать над всеми хотелками сообщества. Некоторые из них приходится ждать годами, а некоторые мы реализуем буквально за день.
Я расскажу о том, как мы работаем с сообществом, мониторим и реализуем запросы. Всегда ли мы это делаем эффективно или что-то можно улучшить?
Приходите! Доклад будет интересен не только тем, кто интересуется Zabbix и мониторингом в целом, но, надеюсь, что и разработчикам открытых программных продуктов.
Очереди и блокировки. Теория и практика / Александр Календарев (ad1.ru)Ontico
В докладе будут описаны паттерны использования очередей и блокировок, рассказано, зачем нужны очереди и блокировки, показано на примерах использования в разных архитектурах.
Описано применение синхронных и асинхронных очередей, как построить очереди с приоритетами.
Будет сравнение разных серверов очередей: Redis, Tarantool, RabbitMQ, ZMQ, Kafka, Zookeeper, MemcacheQ и др., их преимущества и недостатки, где и какой брокер лучше использовать.
Девять кругов ада или PostgreSQL Vacuum / Алексей Лесовский (PostgreSQL-Consu...Ontico
Если вы сталкивались с PostgreSQL и зашли дальше, чем инструкция по установке, то, скорей всего, коротко познакомились с вакуумом, ну или, как минимум, что-то слышали про него.
Вакуум или по-русски очистка - это важная задача в жизненном цикле постгреса, которая заключается в регулярном освобождении базы данных от, так скажем, "мусора". Вакуум очень важен, его нельзя игнорировать и тем более отключать; более того, ему следует уделять должное внимание. А за кажущейся простотой скрывается довольно сложный и интересный механизм, к работе которого очень часто возникает много вопросов, на которые не всегда можно найти однозначный ответ.
В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
"OpenStack & Oracle — взболтать, но не смешивать". Сергей Филимонцев, ЯндексYandex
Все enterprise-решения имеют свою специфику и отличаются весьма щепетильным подходом к эксплуатации. Но иногда возникает необходимость тиражировать их с минимальными усилиями. Нам в Яндексе понадобилось создать множество тестовых сред с продуктами Oracle. Для облегчения этой задачи мы виртуализовали их в приватном облаке OpenStack. В докладе пойдёт речь об этом опыте: с какими проблемами пришлось столкнуться и как мы будем использовать в дальнейшем полученные знания.
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
How to build solid CI-CD pipeline / Илья Беда (beda.software)Ontico
РИТ++ 2017, Root Conf
Зал Конгресс-холл, 6 июня, 15:00
Тезисы:
http://rootconf.ru/2017/abstracts/2551.html
На основе своего опыта работы в консалтинге я расскажу, как избавить разработчиков от рутинных задач и как сэкономить на ресурсах команды с помощью правильно настроенного CI-CD pipeline.
Единствено верный способ упаковки приложений - это Docker-контейнеры, благодаря этому способу вы сможете унифицировать процесс деплоя. Нужно деплоить приложения с помощью Ansible-плейбука, запакованного в Docker-контейнер, это снижает требования к окружению CI-ранера. Вам нужен только Docker.
...
We all have tasks from time to time for bulk-loading external data into MySQL. What's the best way of doing this? That's the task I faced recently when I was asked to help benchmark a multi-terrabyte database. We had to find the most efficient method to reload test data repeatedly without taking days to do it each time. In my presentation, I'll show you several alternative methods for bulk data loading, and describe the practical steps to use them efficiently. I'll cover SQL scripts, the mysqlimport tool, MySQL Workbench import, the CSV storage engine, and the Memcached API. I'll also give MySQL tuning tips for data loading, and how to use multi-threaded clients.
These are the *updated* slides (InnoDB clusters and MySQL Enterprise Monitor 3.4 are now GA) from the following webinar, which you can now watch on demand:
https://www.mysql.com/news-and-events/web-seminars/why-mysql-high-availability-matters/
-----------------------------------------------------
MySQL high availability matters because your data matters. If your database goes down, whether due to human error, catastrophic network failure, or planned maintenance, the accessibility and accuracy of your data can be compromised with disastrous results. We'll examine the critical elements of a high availability solution, including:
- Data redundancy
- Data consistency
- Automatic fault detection and resolution
- No single point of failure
And how you can achieve these things more easily than ever before using MySQL's new native HA solution.
Software developers love tools for coding, debugging, testing, and configuration management. The more these tools improve the How of coding, the more we see that we're behind the curve on improving the What, Why, and When. If you've been on a project that seemed vague, adrift, and endless, this talk can help. Make your projects run SMART.
A tutorial on MySQL High Availability on the Pacemaker stack. Covers both MySQL on DRBD, and MySQL with MySQL replication.
Presented by Florian Haas and Yves Trudeau at the Percona Live MySQL Conference & Expo, 2012
Just about anyone can write a basic SQL query for a table. Not everyone can write a good query though - that takes practice and knowing how to understand what the optimizer is doing with the query. Learn the basics of query optimization so you keep your application engaging the user rather then showing the progress bar as they wait on the database.
This document provides an overview of troubleshooting replication in MySQL and MariaDB databases. It discusses typical errors seen with the slave IO thread and slave SQL thread, such as replication stopping, the slave lagging behind the master, and the master increasing in resource usage. It also covers replication concepts like the master-slave architecture, binary logging formats, global transaction identifiers, and tools for monitoring replication like SHOW SLAVE STATUS and Performance Schema.
MySQL High Availability and Disaster Recovery with Continuent, a VMware companyContinuent
Users seeking high availability, disaster recovery and zero downtime maintenance operation for business-critical MySQL applications face confusing choices. Is multi-master or master/slave clustering better? What about synchronous versus asynchronous replication? Using a plain vanilla, stock MySQL or a modified version of it? Which of these choices are right for data-driven businesses that depend on fast, reliable data access?
This no-BS webinar cuts through the FUD to explore the real trade-offs between the different clustering and replication methods, thens show you how Continuent's asynchronous master/slave clusters support these important capabilities for business-critical applications:
- High application write rates Master/slave clustering with Continuent
- Mixed workloads consisting of large and small transactions
- Data across multiple geographically distributed locations
- Failures and more importantly recovery from them
- Zero downtime maintenance and software upgrades
- Use of off-the-shelf MySQL/MariaDB to avoid application changes and allow clusters to improve as MySQL itself does.
We illustrate key points with demonstrations and case studies from deployed systems.
Everything You Need to Know About MySQL Group ReplicationNuno Carvalho
MySQL Group Replication is a new plugin that implements an exciting extension to the proven and long standing MySQL Replication technology. It leverages advanced distributed protocols to ultimately provide to the end user features such as data replication, high availability, split brain protection and automation.
It can be deployed in single-primary mode (default), in which primary fail-over is handled gracefully and automatically, or in multi-master mode, in which row level conflicts are detected and handled automatically as well. Regardless of the deployment mode, the end result is that this new addition provides a consistent and dependable replicated state machine, thus effectively enabling a fault-tolerant MySQL database service.
At the end of the presentation, you will be able to understand how it works, the use cases it address, its limitations and also its roadmap ahead. Moreover, you will get to know how it fits in the overall high availability roadmap at MySQL.
The document discusses testing HBase source code. It describes the required JAR files for a simple test, inserts test data into HBase tables, and measures the insertion performance. It also summarizes the entry points for HMaster and HRegionServer source code, and describes some common HBase operations like building tables, handling DDL exceptions, flushing, compacting, and splitting regions.
Upgrading MySQL databases do not come without risk. There is no guarantee that no problems will happen if you move to a new major MySQL version.
Should we just upgrade and rollback immediately if problems occur? But what if these problems only happen a few days after migrating to this new version?
You might have a database environment that is risk-adverse, where you really have to be sure that this new MySQL version will handle the workload properly.
Examples:
- Both MySQL 5.6 and 5.7 have a lot of changes in the MySQL Optimizer. It is expected that this improves performance of my queries, but is it really the case? What if there is a performance regression? How will this affect my database performance?
- Also, there are a lot of incompatible changes which are documented in the release notes, how do I know if I'm affected by this in my workload? It's a lot to read..
- Can I go immediately from MySQL 5.5 to 5.7 and skip MySQL 5.6 even though the MySQL documentation states that this is not supported?
- Many companies have staging environments, but is there a QA team and do they really test all functionality, under a similar workload?
This presentation will show you a process, using open source tools, of these types of migrations with a focus on assessing risk and fixing any problems you might run into prior to the migration.
This process can then be used for various changes:
- MySQL upgrades for major version upgrades
- Switching storage engines
- Changing hardware architecture
Additionally, we will describe ways to do the actual migration and rollback with the least amount of downtime.
MHA (MySQL High Availability): Getting started & moving past quirksColin Charles
MHA (Master High Availability Manager) is a tool for automating MySQL master failover and slave promotion with minimal downtime. It consists of Perl scripts that monitor a replication topology and automatically switch a slave to a master if the current master fails. When a failure is detected, MHA identifies the most up-to-date slave and applies any missing binary logs to make it the new master. It then changes the slaves to replicate from the new master. MHA requires installing node packages on all servers and a manager package to coordinate monitoring and failover.
Every website wants to become successful. Few websites however undertake the basic and fundamental steps to build a rock solid foundation to ensure a scalable
The document discusses proposed changes to MySQL Server 8.0 and replication defaults. Some key areas discussed include changing the default character set to UTF8MB4, turning on the event scheduler by default, increasing some session buffer sizes, enabling security defaults, and enabling replication features like binary logging and GTIDs by default. The document seeks feedback from users on the proposed changes.
Mix ‘n’ Match Async and Group Replication for Advanced Replication SetupsPedro Gomes
The document discusses mixing asynchronous replication and group replication for advanced MySQL replication setups. It provides an overview of asynchronous replication, semi-synchronous replication, multi-source replication, and group replication. It then discusses some basic scenarios for mixing these technologies, such as using asynchronous replication for read scaling beyond the group's 9 member limit or aggregating data from multiple groups. The document also covers migrating from asynchronous to group replication and migrating disjoint servers into a group.
High Availability Using MySQL Group ReplicationOSSCube
MySQL Group Replication is a recent MySQL plugin that brings together group communication techniques and database replication, providing both a high availability and a multi-master update everywhere replication solution.
The PPT provide provide a broad overview of MySQL Group Replication plugin, what it can achieve and how it helps keep your MySQL databases highly available and your business up and running, without fail.
MySQL High Availability with Group ReplicationNuno Carvalho
MySQL Group Replication is a multi-master update everywhere replication plugin that provides high availability. It removes the need for handling server failover, provides fault tolerance, and automates group reconfiguration. Transactions are replicated to all group members, with conflicts detected and resolved using a first committer wins rule. Failed members automatically rejoin the group and synchronize with the others transparently. Group Replication uses the standard MySQL and InnoDB architecture, so existing users will feel familiar. It also supports features like auto-increment handling, GTIDs, secure connections, and a new single primary mode.
OpenSource SQL Databases Enter Millions Queries per Second EraSveta Smirnova
Доклад прочитан на Highload++ 8 ноября 2016 года совместно с Фёдором Сигаевым и Анастасией Распопиной. Подготовка слайдов совместно с Александром Коротковым.
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
В докладе я расскажу, как выглядит World of Tanks Server (кластер кластеров) со всеми веб-сервисами, которые существуют вокруг. Какие узкие места с точки зрения отказоустойчивости есть внутри кластера, между кластерами, во взаимодействии с внешними веб-сервисами. Как мы решаем возникающие проблемы технически, процессно, проектно.
Дмитрий Меньшиков "Топ-10 фейлов на реальном highload проекте"Fwdays
- как ошибка выбора идентификатора пользователя, обнаруженная после запуска проекта, чуть не стоила 2 лет разработки
- как мы боролись с перегруженным mysql когда даже включение binlog убивает сервер
- почистил партицию mysql под нагрузкой - получи мертвый сервер
- как верстальщик поменял верстку серча и уложил продукт на 4 часа
- ошибка в ядре php которая привела даунтайм на несколько часов
- как незнание особенностей работы GC у redis обошлось в $50к чистой прибыли
- добавлением или удалением серверов из пула memcached инвалидировали весь кэш (кривые настройки php клиента Memcache/Memcached)
- как поправив тест потерять 2 миллиона пользовательских писем
- как релиз одного проекта крэшил хелсчеки соседнего проекта
- самый большой фейл с системами очередей и статистикой: ивенты терялись годами
Zabbix: рецепты высокопроизводительного мониторинга / Алексей Владышев (Zabbix)Ontico
HighLoad++ 2017
Зал «Дели + Калькутта», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/3007.html
Я расскажу о принципах создания высокопроизводительного мониторинга и о том, какие инструменты для этого существуют в Zabbix.
Проанализируем результаты бенчмарков различных сценариев работы Zabbix, посмотрим, сколько метрик в секунду способна собирать и обрабатывать наша система мониторинга. Отвечу на вопрос, что и как влияет на производительность Zabbix? Будет очень много цифр и графиков!
...
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
"Кластеры баз данных: делаем сложные вещи просто" Андрей Тихонов (Avito)AvitoTech
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
MySQL 2024: Зачем переходить на MySQL 8, если в 5.х всё устраивает?Sveta Smirnova
25 октябрая 2023 года Oracle прекратила активную поддержку MySQL 5.7.
Это значит, что стоит присмотреться к улучшениям в версии 8:
- Новому системному словарю
- Современному SQL
- Поддержке JSON, NoSQL, MySQL Shell, и возможности работать с MySQL как с MongoDB
- Улучшениям в оптимизаторе запросов и диагностике
Мой доклад для разработчиков приложений под MySQL. Я не буду рассказывать как конфигурировать сервер и сфокусируюсь на его использовании.
Database in Kubernetes: Diagnostics and MonitoringSveta Smirnova
Kubernetes is the new cool in 2023. Many database installations are on Kubernetes now. And this creates challenges for Support engineers because traditional monitoring and diagnostic tools work differently on bare hardware and Kubernetes. In this session, I will focus on differences in methods we use to collect metrics, describe challenges that Percona Support hits when working with database installations on Kubernetes, and discuss how we resolve them. This talk will cover all database technologies we support: MySQL, MongoDB, and PostgreSQL.
Presented at Percona Live 2023
MySQL Database Monitoring: Must, Good and Nice to HaveSveta Smirnova
It is very easy to find if a database installation is having issues. You only need to enable Operating System monitoring. A disk, memory, or CPU usage change will alert you about the problems. But they would not show *why* the trouble happens. You need the help of database-specific monitoring tools.
As a Support Engineer, I am always very upset when handling complaints about the database behavior lacking specific database monitoring data because I cannot help!
There are two reasons database and system administrators do not enable necessary instrumentation. The first is a natural or expected performance impact. Second is the lack of knowledge on what needs to be on to resolve a particular issue.
In this talk, I will cover both concerns.
I will show which monitoring instruments will give information on what causes disk, memory, or CPU problems.
I will teach you how to use them.
I will uncover which performance impact these instruments have.
I will use both MySQL command-line client and open-source graphical instrument Percona Monitoring and Management (PMM) for the examples.
This document provides an overview of the MySQL Cookbook by O'Reilly. It discusses the intended audience of database administrators and developers. It also demonstrates different ways of interacting with MySQL, including through the command line interface, MySQL Shell, and X DevAPI. Examples are provided for common tasks like reading, writing, and updating data in both standard SQL and the object-oriented X DevAPI.
MySQL performance can be improved by tuning queries, server options, and hardware. Traditionally it was an area of responsibility for three different roles: Development, DBA, and System Administrators. Now DevOps handle these all. But there is a gap. Knowledge gained by MySQL DBAs after years or focusing on a single product is hard to gain when you focus on more than one. This is why I am doing this session. I will show a minimal but most effective set of options to improve MySQL performance. For illustrations, I will use real user stories gained from my Support experience and Percona Kubernetes operators for PXC and MySQL.
MySQL Test Framework для поддержки клиентов и верификации баговSveta Smirnova
Talk for TestDriven Conf: https://tdconf.ru/2022/abstracts/8763
MySQL Test Framework (MTR) — это фреймворк для регрессионных тестов MySQL. Тесты для него пишут разработчики MySQL и запускаются во время подготовки к новым релизам.
MTR можно использовать и по-другому. Я его использую, чтобы тестировать проблемы, о которых сообщают клиенты, и подтверждать сообщения об ошибках (bug reports) одновременно на нескольких версиях MySQL.
При помощи MTR можно:
* программировать сложные развёртывания;
* тестировать проблему на нескольких версиях MySQL/Percona/MariaDB-серверов при помощи одной команды;
* тестировать несколько одновременных соединений;
* проверять ошибки и возвращаемые значения;
* работать с результатами запросов, хранимыми процедурами и внешними командами.
Тест может быть запущен на любой машине с MySQL-, Percona- или MariaDB-сервером.
Я покажу, как я работаю с MySQL Test Framework, и надеюсь, что вы тоже полюбите этот инструмент.
This document provides an overview of different ways to work with MySQL using standard SQL, X DevAPI, and MySQL Shell utilities. It discusses querying, updating, and exporting/importing data using these different approaches. It also covers topics like character encoding, generating summaries, storing errors, and retrieving metadata. Examples are provided to illustrate concepts like selecting, grouping, joining, changing data, common table expressions, and more using SQL and X DevAPI. MySQL Shell utilities for exporting/importing CSV, JSON, and working with collections are also demonstrated.
Introduction into MySQL Query Tuning for Dev[Op]sSveta Smirnova
Percona Live Online 2021 talk: https://www.percona.com/resources/videos/introduction-mysql-query-tuning-for-devops
In this talk I will show how to get started with MySQL Query Tuning. I will make a short introduction into physical table structure and demonstrate how it may influence query execution time.
Then we will discuss basic query tuning instruments and techniques, mainly EXPLAIN command with its latest variations. You will learn how to understand its output and how to rewrite queries or change table structure to achieve better performance.
This document provides an overview of optimizing MySQL performance for DevOps. It discusses hardware configuration including memory, disk, CPU and network. It covers important MySQL configuration options like InnoDB settings. It also discusses query tuning techniques like using indexes to improve query performance.
How to Avoid Pitfalls in Schema Upgrade with Percona XtraDB ClusterSveta Smirnova
Percona XtraDB Cluster (PXC) is a 100% synchronized cluster in regards to DML operations. It is ensured by the optimistic locking model and ability to rollback transaction which cannot be applied on all nodes. However, DDL operations are not transactional in MySQL. This adds complexity when you need to change the schema of the database.
Changes made by DDL may affect the results of the queries. Therefore all modifications must replicate on all nodes prior to the next data access. For operations that run momentarily, it can be easily achieved, but schema changes may take hours to apply. Therefore in addition to the safest synchronous blocking schema upgrade method: TOI, - PXC supports more relaxed, though not safe, method RSU.
RSU: Rolling Schema Upgrade is advertised to be non-blocking. But you still need to take care of updates, running while you are performing such an upgrade. Surprisingly, even updates on not related tables and schema can cause RSU operation to fail.
In this talk, I will uncover nuances of PXC schema upgrades and point to details you need to take special care about.
Further Information
Schema change is a frequent task, and many do not expect any surprises with it. However, the necessity to replay the changes to all synchronized nodes adds complexity. I made a webinar on a similar topic which was recorded and available for replay. Now I have found that I share a link to the webinar to my Support customers approximately once per week. Not having a good understanding of how schema change works in the cluster leads to lockups and operation failures. This talk will provide a checklist that will help to choose the best schema change method.
Presented at Percona Live Online: https://perconaliveonline2020.sched.com/event/ePm2/how-to-avoid-pitfalls-in-schema-upgrade-with-percona-xtradb-cluster
How to migrate from MySQL to MariaDB without tearsSveta Smirnova
Presented at MariaDB Server Fest 2020: https://mariadb.org/fest2020/migrate-mysql/
MariaDB is a drop-in replacement for MySQL. Initial migration is simple: start MariaDB over the old MySQL datadir.
Later your application may notice that some features work differently than with MySQL. These are MariaDB improvements, so this is good and, likely the reason you migrated.
In this session, I will focus on the differences affecting application performance and behavior. In particular, features sharing the same name, but working differently.
Modern solutions for modern database load: improvements in the latest MariaDB...Sveta Smirnova
Presented at MariaDB Server Fest 2020: https://mariadb.org/fest2020/improvements/
MariaDB is famous for working well in high-performance environments. But our view of what to call high-performance changes over time. Every year we get faster data transfer speed; more devices connected to the Internet; more users and, as a result, more data.
Challenges, which developers have to solve, are getting harder. This session shows what engineers do to keep the product up to date, focusing on MariaDB improvements that make it different from its predecessor, MySQL.
How Safe is Asynchronous Master-Master Setup?Sveta Smirnova
Presented at Percona MySQL Tech Day on September 10, 2020: https://www.percona.com/tech-days#mysql
It is common knowledge that built-in asynchronous active-active replication is not safe. I remember times when the official MySQL User Reference Manual stated that such an installation is not recommended for production use. Some experts repeat this claim even now.
While this statement is generally true, I worked with thousands of shops that successfully avoided asynchronous replication limitations in active-active setups.
In this talk, I will show how they did it, demonstrate situations when asynchronous source-source replication is the best possible high availability option and beats such solutions as Galera or InnoDB Clusters. I will also cover common mistakes, leading to disasters.
How to Avoid Pitfalls in Schema Upgrade with GaleraSveta Smirnova
This document discusses different methods for performing schema upgrades in a Galera cluster, including Total Order Isolation (TOI), Rolling Schema Upgrade (RSU), and the pt-online-schema-change tool. TOI blocks the entire cluster during DDL but ensures consistency, while RSU allows upgrades without blocking the cluster but requires stopping writes and carries risks of inconsistency. Pt-online-schema-change performs non-blocking upgrades using triggers to copy rows to a new table in chunks.
How Safe is Asynchronous Master-Master Setup?Sveta Smirnova
This document discusses the risks of using asynchronous master-master replication for MySQL databases and provides strategies for setting it up safely. It explains that having two nodes actively accepting writes can lead to conflicts like duplicate key errors. It recommends dividing writes across nodes by database, table, or row to avoid conflicts. The document also discusses using synchronous replication tools like Galera to ensure consistency across nodes at the cost of reduced performance.
Introduction to MySQL Query Tuning for Dev[Op]sSveta Smirnova
To get data, we query the database. MySQL does its best to return requested bytes as fast as possible. However, it needs human help to identify what is important and should be accessed in the first place.
Queries, written smartly, can significantly outperform automatically generated ones. Indexes and Optimizer statistics, not limited to the Histograms only, help to increase the speed of the query a lot.
In this session, I will demonstrate by examples of how MySQL query performance can be improved. I will focus on techniques, accessible by Developers and DevOps rather on those which are usually used by Database Administrators. In the end, I will present troubleshooting tools which will help you to identify why your queries do not perform. Then you could use the knowledge from the beginning of the session to improve them.
Billion Goods in Few Categories: How Histograms Save a Life?Sveta Smirnova
We store data with an intention to use it: search, retrieve, group, sort... To do it effectively the MySQL Optimizer uses index statistics when compiles the query execution plan. This approach works excellently unless your data distribution is not even.
Last year I worked on several tickets where data follow the same pattern: millions of popular products fit into a couple of categories and rest used the rest. We had a hard time to find a solution for retrieving goods fast. We offered workarounds for version 5.7. However new MariaDB and MySQL 8.0 feature: histograms, - would work better, cleaner and faster. The idea of the talk was born.
Of course, histograms are not a panacea and do not help in all situations.
I will discuss:
how index statistics physically stored by the storage engine
which data exchanged with the Optimizer
why it is not enough to make correct index choice
when histograms can help and when they cannot
differences between MySQL and MariaDB histograms
A Billion Goods in a Few Categories: When Optimizer Histograms Help and When ...Sveta Smirnova
Last year this session’s speaker worked on several cases where data followed the same pattern: millions of popular products fit into a couple of categories, and the rest uses the rest. Her team had a hard time finding a solution for retrieving goods quickly. MySQL 8.0 has a feature that resolves such issues: optimizer histograms, storing statistics of an exact number of values in each data bucket. In real life, histograms don’t help with all queries accessing nonuniform data. How you write a statement, the number of rows in the table, data distribution: All of these may affect the use of histograms. This presentation shows examples demonstrating how the optimizer works in each case, describes how to create histograms, and covers differences between MySQL and Oracle implementations.
Billion Goods in Few Categories: How Histograms Save a Life?Sveta Smirnova
We store data with an intention to use it: search, retrieve, group, sort... To do it effectively, the MySQL Optimizer uses index statistics when it compiles the query execution plan. This approach works excellently unless your data distribution is not even.
Last year I worked on several support tickets where data follows the same pattern: millions of popular products fit into a couple of categories and the rest used the rest. We had a hard time finding a solution for retrieving goods fast. We offered workarounds for version 5.7. However, a new MariaDB and MySQL 8.0 feature - histograms - would work better, cleaner and faster. The idea of the talk was born.
Of course, histograms are not a panacea and do not help in all situations.
I will discuss
- how index statistics physically stored by the storage engine
- which data exchanged with the Optimizer
- why it is not enough to make correct index choice
- when histograms can help and when they cannot
- differences between MySQL and MariaDB histograms
Talk for Percona Live 2019 Austin: https://www.percona.com/live/19/sessions/billion-goods-in-few-categories-how-histograms-save-a-life
Performance Schema is a powerful diagnostic instrument for:
- Query performance
- Complicated locking issues
- Memory leaks
- Resource usage
- Problematic behavior, caused by inappropriate settings
- More
It comes with hundreds of options which allow precisely tuning what to instrument. More than 100 consumers store collected data.
In this tutorial, we will try all the important instruments out. We will provide a test environment and a few typical problems which could be hardly solved without Performance Schema. You will not only learn how to collect and use this information but have experience with it.
Tutorial at Percona Live Austin 2019
2. ∙
Инженер тех. поддержки MySQL
∙ Автор
∙ MySQL Troubleshooting
∙ JSON UDF функции
∙ FILTER clause для MySQL
∙ Докладчик
∙ Percona Live, OOW, Fosdem,
DevConf, ...
Света Смирнова
2
22. $ perror 1045
MySQL error code 1045 (ER_ACCESS_DENIED_ERROR): Access denied for user ’%-.48s’@’%-.64s’
(using password: %s)
№4: perror
17
23. ∙
На слейве
$ mysql -h127.0.0.1 -P13000 -uslave_user -pslave_password
Warning: Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user ’slave_user’@’localhost’ (using password: YES
№5: MySQL Command Line Client
18
24. ∙
На слейве
∙
На мастере
mysql> SHOW GRANTS;
+-----------------------------------------+
| Grants for slave_user@% |
+-----------------------------------------+
| GRANT SELECT ON *.* TO ’slave_user’@’%’ |
+-----------------------------------------+
1 row in set (0.00 sec)
№5: MySQL Command Line Client
18
32. ∙ Запись на мастере медленнее асинхронной
Полусинхронная: с точки зрения отладки
20
33. ∙ Запись на мастере медленнее асинхронной
∙ Сколько "Ack"-ов ждёт мастер?
Полусинхронная: с точки зрения отладки
20
34. ∙ Запись на мастере медленнее асинхронной
∙ Сколько "Ack"-ов ждёт мастер?
∙ До версии 5.7: от одного слейва
Полусинхронная: с точки зрения отладки
20
35. ∙ Запись на мастере медленнее асинхронной
∙ Сколько "Ack"-ов ждёт мастер?
∙ До версии 5.7: от одного слейва
∙
Сейчас в MySQL:
rpl_semi_sync_master_wait_for_slave_count
Полусинхронная: с точки зрения отладки
20
36. ∙ Запись на мастере медленнее асинхронной
∙ Сколько "Ack"-ов ждёт мастер?
∙ До версии 5.7: от одного слейва
∙
Сейчас в MySQL:
rpl_semi_sync_master_wait_for_slave_count
∙ Остальных ждать не будет
Полусинхронная: с точки зрения отладки
20
37. ∙ Запись на мастере медленнее асинхронной
∙ Сколько "Ack"-ов ждёт мастер?
∙ Что происходит при timeout-е?
Полусинхронная: с точки зрения отладки
20
38. ∙ Запись на мастере медленнее асинхронной
∙ Сколько "Ack"-ов ждёт мастер?
∙ Что происходит при timeout-е?
∙ Репликация становится асинхронной
Полусинхронная: с точки зрения отладки
20
39. ∙ Запись на мастере медленнее асинхронной
∙ Сколько "Ack"-ов ждёт мастер?
∙ Что происходит при timeout-е?
∙
Что значит "Ack"?
Полусинхронная: с точки зрения отладки
20
40. ∙ Запись на мастере медленнее асинхронной
∙ Сколько "Ack"-ов ждёт мастер?
∙ Что происходит при timeout-е?
∙
Что значит "Ack"?
∙ Событие записано в relay log
Полусинхронная: с точки зрения отладки
20
41. ∙ Запись на мастере медленнее асинхронной
∙ Сколько "Ack"-ов ждёт мастер?
∙ Что происходит при timeout-е?
∙
Что значит "Ack"?
∙ Событие записано в relay log
∙ Неизвестно, выполнено ли оно
Полусинхронная: с точки зрения отладки
20
55. ∙
Разные данные
∙
Слейв не может выполнить event из relay log
∙ Разные ошибки на мастере и слейве
∙ Триггеры
∙ Транзакционные и нетранзакционные
таблицы одновременно
Какие Бывают Ошибки?
28
56. ∙ Таблица менялась вне репликации?
∙ Как?
∙
Конфликт с обновлениями на мастере?
Разные Данные на Мастере и Слейве
29
57. ∙ Таблица менялась вне репликации?
∙ Идентична ли структура таблиц?
∙ Percona Toolkit
pt-table-checksum, pt-table-sync
∙
MySQL Utilities
mysqlrplsync, mysqldbcompare, mysqldiff
Разные Данные на Мастере и Слейве
29
58. ∙ Таблица менялась вне репликации?
∙ Идентична ли структура таблиц?
∙ Обновления в неправильном порядке?
∙ mysqlbinlog
∙
Логика приложения на мастере
Разные Данные на Мастере и Слейве
29
64. Мастер
Получает изменение
Передаёт движку ->
Пишет в binary log
Синхронизируется ->
Табличный движок
Пишет в таблицу
<- Передаёт управление
<- Синхронизируется
Логическая
30
78. ∙ Существует с первых версий
∙ Мало чувствительна к структуре таблиц на
слейве
SBR: Сильные Стороны
34
79. ∙ Существует с первых версий
∙ Мало чувствительна к структуре таблиц на
слейве
∙
Экономна
SBR: Сильные Стороны
34
80. ∙ Существует с первых версий
∙ Мало чувствительна к структуре таблиц на
слейве
∙
Экономна
∙ Понятна человеку
SBR: Сильные Стороны
34
81. ∙ Существует с первых версий
∙ Мало чувствительна к структуре таблиц на
слейве
∙
Экономна
∙ Понятна человеку
∙ Легко отлаживать
SBR: Сильные Стороны
34
82. mysql> SHOW BINLOG EVENTS IN ’mysql-bin.000316’ FROM 422;
+------------------+-----+------------+------------+-------------+---------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+-----+------------+------------+-------------+---------------------------------+
| mysql-bin.000316 | 422 | Query | 1456667904 | 509 | BEGIN |
| mysql-bin.000316 | 509 | Query | 1456667904 | 609 | use ‘PgDay‘; update ai set f1=1 |
| mysql-bin.000316 | 609 | Xid | 1456667904 | 640 | COMMIT /* xid=60328 */ |
+------------------+-----+------------+------------+-------------+---------------------------------+
3 rows in set (0,12 sec)
№7: SHOW BINLOG EVENTS
35
83. ∙ Не все запросы одинаково безопасны
∙ Non-deterministic функции
∙
Расширения MySQL
∙ Триггеры
∙ Таблицы транзакционные и нет
∙ Временные таблицы
SBR: Слабые Стороны
36
84. ∙ Не все запросы одинаково безопасны
∙ Порядок имеет значение!
∙
Построчные блокировки
SBR: Слабые Стороны
36
85. ∙ Только при использовании SBR
Обновления в неправильном порядке
37
86. ∙ Только при использовании SBR
∙ Блокировки на уровне строк
Обновления в неправильном порядке
37
87. ∙ Только при использовании SBR
∙ Блокировки на уровне строк
∙ Триггеры
∙ SET GLOBAL slave_skip_counter– No GTIDs!
∙
Пропустите транзакцию – GTIDs
∙
Синхронизируйте таблицы!
Обновления в неправильном порядке
37
88. ∙ Только при использовании SBR
∙ Блокировки на уровне строк
∙ Триггеры
∙
Разные опции: для олдфагов
∙ Запустите слейв с опциями мастера
∙ Перезапустите SQL thread
∙
Исправлено в последних версиях
Обновления в неправильном порядке
37
93. Клиент
UPDATE ... ->
Binary log
SET TIMESTAMP...
SET sql_mode...
Строка до изменений
Row-Based Binary Log Format
38
94. Клиент
UPDATE ... ->
Binary log
SET TIMESTAMP...
SET sql_mode...
Строка до изменений
Строка с изменениями
Row-Based Binary Log Format
38
95. ∙
Безопасность
∙ Вам больше не нужно заботиться о
Порядке
Триггерах
Функциях
Какие запросы вы посылаете мастеру
RBR: Сильные Стороны
39
96. ∙ Более чувствительна к структуре таблиц
∙ Как правило больше данных
∙
––binlog_row_image=FULL | MINIMAL | NOBLOB
∙ Сложнее отлаживать
RBR: Слабые Стороны
40
97. $ mysqlbinlog var/mysqld.1/data/master-bin.000001 –start-position=989 –stop-position=1213
...
# at 1167
#160822 14:15:11 server id 1 end_log_pos 1213 CRC32 0x1f346c6b
Update_rows: table id 109 flags: STMT_END_F
BINLOG ’
v966VxMBAAAAKwAAAI8EAAAAAG0AAAAAAAEAAm0yAAJ0MQABAwABY2HOoQ==
v966Vx8BAAAALgAAAL0EAAAAAG0AAAAAAAEAAgAB///+BQAAAP4GAAAAa2w0Hw==
’/*!*/;
ROLLBACK /* added by mysqlbinlog */ /*!*/;
SET @@SESSION.GTID_NEXT= ’AUTOMATIC’ /* added by mysqlbinlog */ /*!*/;
...
№8: mysqlbinlog
41
98. $ mysqlbinlog -v var/mysqld.1/data/master-bin.000001 –start-position=989 –stop-position=1213
...
# at 1167
#160822 14:15:11 server id 1 end_log_pos 1213 CRC32 0x1f346c6b
Update_rows: table id 109 flags: STMT_END_F
BINLOG ’
v966VxMBAAAAKwAAAI8EAAAAAG0AAAAAAAEAAm0yAAJ0MQABAwABY2HOoQ==
v966Vx8BAAAALgAAAL0EAAAAAG0AAAAAAAEAAgAB///+BQAAAP4GAAAAa2w0Hw==
’/*!*/;
### UPDATE ‘m2‘.‘t1‘
### WHERE
### @1=5
### SET
### @1=6
ROLLBACK /* added by mysqlbinlog */ /*!*/;
SET @@SESSION.GTID_NEXT= ’AUTOMATIC’ /* added by mysqlbinlog */ /*!*/;
№8: mysqlbinlog
42
100. ∙ Необходимо указать
∙
Название binary log на мастере
∙ Позицию
∙ С точки зрения отладки
∙
Событие выполняется по указателю позиции
Позиционная
43
101. ∙ Необходимо указать
∙
Название binary log на мастере
∙ Позицию
∙ С точки зрения отладки
∙
Событие выполняется по указателю позиции
∙ Легко пропустить
Позиционная
43
102. ∙ Необходимо указать
∙
Название binary log на мастере
∙ Позицию
∙ С точки зрения отладки
∙
Событие выполняется по указателю позиции
∙ Легко пропустить
∙ Легко переместить указатель в прошлое
Позиционная
43
103. ∙ Необходимо указать
∙
Название binary log на мастере
∙ Позицию
∙ С точки зрения отладки
∙
Событие выполняется по указателю позиции
∙ Легко пропустить
∙ Легко переместить указатель в прошлое
∙ Нет проверок
Позиционная
43
104. ∙ Каждая транзакция получает номер: GTID
Глобальные идентификаторы транзакций (GTID)
44
105. ∙ Каждая транзакция получает номер: GTID
∙ MySQL: AUTO_POSITION=1
Глобальные идентификаторы транзакций (GTID)
44
107. ∙ Каждая транзакция получает номер: GTID
∙ MySQL: AUTO_POSITION=1
∙
MariaDB: master_use_gtid = { slave_pos | current_pos }
∙
Не нужно указывать binary log и позицию
Глобальные идентификаторы транзакций (GTID)
44
108. ∙ Каждая транзакция получает номер: GTID
∙ MySQL: AUTO_POSITION=1
∙
MariaDB: master_use_gtid = { slave_pos | current_pos }
∙
Не нужно указывать binary log и позицию
∙
Сложно исправить ошибку
Глобальные идентификаторы транзакций (GTID)
44
109. sveta@thinkie> mysqlslavetrx –gtid-set=fb776095-8474-11e5-ad41-30b5c2208a0f:3
–slaves=root:@127.0.0.1:13001
WARNING: Using a password on the command line interface can be insecure.
#
# GTID set to be skipped for each server:
# - 127.0.0.1@13001: fb776095-8474-11e5-ad41-30b5c2208a0f:3
#
# Injecting empty transactions for ’127.0.0.1:13001’...
#
#...done.
#
№9: mysqlslavetrx
45
112. ∙ Несколько наборов relay log
Несколько Мастеров: С Точки Зрения Отладки
48
113. ∙ Несколько наборов relay log
∙ Несколько IO thread-ов
Несколько Мастеров: С Точки Зрения Отладки
48
114. ∙ Несколько наборов relay log
∙ Несколько IO thread-ов
∙ Несколько SQL thread-ов
Несколько Мастеров: С Точки Зрения Отладки
48
115. ∙ Несколько наборов relay log
∙ Несколько IO thread-ов
∙ Несколько SQL thread-ов
∙
MySQL: ––slave_parallel_workers для каждого
Несколько Мастеров: С Точки Зрения Отладки
48
116. ∙ Несколько наборов relay log
∙ Несколько IO thread-ов
∙ Несколько SQL thread-ов
∙
MySQL: ––slave_parallel_workers для каждого
∙
Каналы независимые
Несколько Мастеров: С Точки Зрения Отладки
48
117. ∙ Несколько наборов relay log
∙ Несколько IO thread-ов
∙ Несколько SQL thread-ов
∙
MySQL: ––slave_parallel_workers для каждого
∙
Каналы независимые
∙
Ошибка на одном остановит только его
Несколько Мастеров: С Точки Зрения Отладки
48
118. ∙ Несколько наборов relay log
∙ Несколько IO thread-ов
∙ Несколько SQL thread-ов
∙
MySQL: ––slave_parallel_workers для каждого
∙
Каналы независимые
∙
Ошибка на одном остановит только его
∙
Одноимённые объекты =⇒ конфликты
Несколько Мастеров: С Точки Зрения Отладки
48
127. ∙ Лог ошибок
∙ На слэйве
∙ SHOW SLAVE STATUS
∙
MySQL: Таблицы в Performance Schema
∙ Системная база mysql
Основные Инструменты
54
128. ∙ Лог ошибок
∙ На слэйве
∙ На мастере
∙ SHOW MASTER STATUS
∙
SHOW BINLOG EVENTS
∙
mysqlbinlog
Основные Инструменты
54
129. ∙ Лог ошибок
∙ На слэйве
∙ На мастере
∙
Percona Toolkit
Основные Инструменты
54
130. ∙ Лог ошибок
∙ На слэйве
∙ На мастере
∙
Percona Toolkit
∙
MySQL Utilities
Основные Инструменты
54
131. ∙
Всегда доступна, требует настройки
∙
Асинхронная
∙
Мастер
∙ Хранит все изменения в binary log
Два формата: ROW и STATEMENT
∙ Слейв
∙
IO thread реплицирует с мастера в relay log
∙ SQL thread исполняет обновления
Несколько SQL thread-ов в 5.6+
Несколько каналов (мастеров) в 5.7+
∙ GTID в 5.6+
Особенности Репликации
55
132. ∙
Мастер
∙ Те же, что и для обычного сервера
∙ Больше пишет и проверяет
Основные Проблемы
56
133. ∙
Мастер
∙
Slave IO thread
∙ Обычные проблемы с сетью
∙ mysql command line client для тестов
Основные Проблемы
56
134. ∙
Мастер
∙
Slave IO thread
∙
Slave SQL thread
∙ Обычные проблемы при выполнении запросов
∙ Обычные проблемы движка
∙
Меньше потоков выполнения, чем на мастере
Основные Проблемы
56
135. ∙ Basic Techniques – troubleshooting webinar
∙
Troubleshooting hardware resource usage
∙ Introduction into storage engine troubleshoot...
∙
Percona Toolkit
∙ MySQL Utilities
∙
Книга MySQL High Availability
∙ MySQL Replication Team blog
Больше информации
57