Что нужно знать о трёх топовых фичах MySQLSveta Smirnova
MySQL прочно удерживает второе по популярности место после Oracle в рейтинге DB-engines: https://db-engines.com/en/ranking_trend Репликация, табличные движки и поддержка NoSQL не дают MySQL сдавать позиции с 2012 года: года основания рейтинга. Что особенного в этих фичах? Что нужно знать, чтобы использовать их на полную мощность?
Я расскажу про дизайн. Именно он отвечает за то, чтобы ваше приложение не достигло потолка производительности. Понимание архитектуры поможет при проектирование нового приложения, которое впоследствии будет легко масштабироваться.
Доклад рассчитан для начинающих пользователей MySQL. Однако поможет освежить свои знания и более опытным.
Slides of the talk held at JEEConf, Kiev and jPrime, Sofia. A personal view on the classic topics from the Uncle Bob's Clean Code bible, with some personal additions and tips&tricks. This topic actually represents the core of the training sessions that I provide as an independent trainer (www.victorrentea.ro)
이번 웨비나에서는 여러분에게 MySQL 성능 튜닝에 대한 깊이 있는 소개를 통해 많은 경험과 전문지식을 배울 수 있는 기회를 제공할 것입니다. 모범 사례를 검토하고 가장 중요한 설정, 초기 MySQL 설정파일, 모니터링 및 그 밖의 것을 다룰 것입니다.
MySQL Workbench, MySQL Enterprise Monitor, 또는 sys schema에서 제공하는 성능 리포트를 이용하여 최적화가 필요한 쿼리를 어떻게 찾는지 배워봅시다.
Что нужно знать о трёх топовых фичах MySQLSveta Smirnova
MySQL прочно удерживает второе по популярности место после Oracle в рейтинге DB-engines: https://db-engines.com/en/ranking_trend Репликация, табличные движки и поддержка NoSQL не дают MySQL сдавать позиции с 2012 года: года основания рейтинга. Что особенного в этих фичах? Что нужно знать, чтобы использовать их на полную мощность?
Я расскажу про дизайн. Именно он отвечает за то, чтобы ваше приложение не достигло потолка производительности. Понимание архитектуры поможет при проектирование нового приложения, которое впоследствии будет легко масштабироваться.
Доклад рассчитан для начинающих пользователей MySQL. Однако поможет освежить свои знания и более опытным.
Slides of the talk held at JEEConf, Kiev and jPrime, Sofia. A personal view on the classic topics from the Uncle Bob's Clean Code bible, with some personal additions and tips&tricks. This topic actually represents the core of the training sessions that I provide as an independent trainer (www.victorrentea.ro)
이번 웨비나에서는 여러분에게 MySQL 성능 튜닝에 대한 깊이 있는 소개를 통해 많은 경험과 전문지식을 배울 수 있는 기회를 제공할 것입니다. 모범 사례를 검토하고 가장 중요한 설정, 초기 MySQL 설정파일, 모니터링 및 그 밖의 것을 다룰 것입니다.
MySQL Workbench, MySQL Enterprise Monitor, 또는 sys schema에서 제공하는 성능 리포트를 이용하여 최적화가 필요한 쿼리를 어떻게 찾는지 배워봅시다.
Most of us use Design Patterns on a daily basis without noticing. Design patterns are commonly defined as solutions to recurring design problems. Frameworks like Laravel use Design Patterns throughout the codebase to keep structure and maintainability. In this talk we will explore the Design Patterns used in Laravel.
This tutorial covers all parallel replication implementation in MariaDB 10.0 and 10.1 and MySQL 5.6, 5.7 and 8.0 (including how it works in Group Replication).
MySQL and MariaDB have different types of parallel replication. In this tutorial, we present the different implementations that allow us to understand their limitations and tuning parameters. We cover how to make parallel replication faster and what to avoid for maximizing its benefits. We also present tests from Booking.com workloads.
Some of the subjects that are covered are group commit and optimistic parallel replication in MariaDB, the parallelism interval of MySQL and its Write Set optimization, and the ?slowing down the master to speed up the slave? optimization.
After this tutorial, you will know everything you need to implement and tune parallel replication in your environment. But more importantly, we will show how you can test parallel replication benefit in a non-disruptive way before deployment.
MySQL Parallel Replication: All the 5.7 and 8.0 Details (LOGICAL_CLOCK)Jean-François Gagné
To get better replication speed and less lag, MySQL implements parallel replication in the same schema, also known as LOGICAL_CLOCK. But fully benefiting from this feature is not as simple as just enabling it.
In this talk, I explain in detail how this feature works. I also cover how to optimize parallel replication and the improvements made in MySQL 8.0 and back-ported in 5.7 (Write Sets), greatly improving the potential for parallel execution on replicas (but needing RBR).
Come to this talk to get all the details about MySQL 5.7 and 8.0 Parallel Replication.
- MariaDB 소개
- MariaDB 서버 구성 및 아키텍처 이해
- MariaDB 스토리지 엔진
- MariaDB 데이터베이스 관리
- 트랜잭션 / Locking 의 이해
- MariaDB 보안
- 백업과 복구를 통한 데이터베이스 관리
- MariaDB upgrade
- MariaDB 모니터링
- MySQL 에서 MariaDB 로의 전환
OpenSource SQL Databases Enter Millions Queries per Second EraSveta Smirnova
Доклад прочитан на Highload++ 8 ноября 2016 года совместно с Фёдором Сигаевым и Анастасией Распопиной. Подготовка слайдов совместно с Александром Коротковым.
Percona Live 2016 (https://www.percona.com/live/data-performance-conference-2016/sessions/why-use-explain-formatjson). Although EXPLAIN FORMAT=JSON was first presented a long time ago, there still aren't many resources that explain how and why to use it. The most advertised feature is visual EXPLAIN in MySQL Workbench, but this format can do more than create nice pictures. It prints additional information that can't be found in good old tabular EXPLAIN, and can help to solve many tricky performance issues. In this session, I will not only describe which additional information we can get with the new syntax, but also provide examples showing how to use it to diagnose production issues.
Most of us use Design Patterns on a daily basis without noticing. Design patterns are commonly defined as solutions to recurring design problems. Frameworks like Laravel use Design Patterns throughout the codebase to keep structure and maintainability. In this talk we will explore the Design Patterns used in Laravel.
This tutorial covers all parallel replication implementation in MariaDB 10.0 and 10.1 and MySQL 5.6, 5.7 and 8.0 (including how it works in Group Replication).
MySQL and MariaDB have different types of parallel replication. In this tutorial, we present the different implementations that allow us to understand their limitations and tuning parameters. We cover how to make parallel replication faster and what to avoid for maximizing its benefits. We also present tests from Booking.com workloads.
Some of the subjects that are covered are group commit and optimistic parallel replication in MariaDB, the parallelism interval of MySQL and its Write Set optimization, and the ?slowing down the master to speed up the slave? optimization.
After this tutorial, you will know everything you need to implement and tune parallel replication in your environment. But more importantly, we will show how you can test parallel replication benefit in a non-disruptive way before deployment.
MySQL Parallel Replication: All the 5.7 and 8.0 Details (LOGICAL_CLOCK)Jean-François Gagné
To get better replication speed and less lag, MySQL implements parallel replication in the same schema, also known as LOGICAL_CLOCK. But fully benefiting from this feature is not as simple as just enabling it.
In this talk, I explain in detail how this feature works. I also cover how to optimize parallel replication and the improvements made in MySQL 8.0 and back-ported in 5.7 (Write Sets), greatly improving the potential for parallel execution on replicas (but needing RBR).
Come to this talk to get all the details about MySQL 5.7 and 8.0 Parallel Replication.
- MariaDB 소개
- MariaDB 서버 구성 및 아키텍처 이해
- MariaDB 스토리지 엔진
- MariaDB 데이터베이스 관리
- 트랜잭션 / Locking 의 이해
- MariaDB 보안
- 백업과 복구를 통한 데이터베이스 관리
- MariaDB upgrade
- MariaDB 모니터링
- MySQL 에서 MariaDB 로의 전환
OpenSource SQL Databases Enter Millions Queries per Second EraSveta Smirnova
Доклад прочитан на Highload++ 8 ноября 2016 года совместно с Фёдором Сигаевым и Анастасией Распопиной. Подготовка слайдов совместно с Александром Коротковым.
Percona Live 2016 (https://www.percona.com/live/data-performance-conference-2016/sessions/why-use-explain-formatjson). Although EXPLAIN FORMAT=JSON was first presented a long time ago, there still aren't many resources that explain how and why to use it. The most advertised feature is visual EXPLAIN in MySQL Workbench, but this format can do more than create nice pictures. It prints additional information that can't be found in good old tabular EXPLAIN, and can help to solve many tricky performance issues. In this session, I will not only describe which additional information we can get with the new syntax, but also provide examples showing how to use it to diagnose production issues.
Performance Schema for MySQL TroubleshootingSveta Smirnova
Percona Live (https://www.percona.com/live/data-performance-conference-2016/sessions/performance-schema-mysql-troubleshooting)
The performance schema in MySQL version 5.6, released in February, 2013, is a very powerful tool that can help DBAs discover why even the trickiest performance issues occur. Version 5.7 introduces even more instruments and tables. And while all these give you great power, you can get stuck choosing which instrument to use.
In this session, I will start with a description of a typical problem, then guide you how to use the performance schema to find out what causes the issue, the reason for unwanted behavior and how the received information can help you solve a particular problem.
Traditionally, performance schema sessions teach what is in contained in tables. I will, in contrast, start from a performance issue, then demonstrate which instruments and tables can help solve it. We will discuss how to setup the performance schema so that it has minimal impact on your server.
Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico
Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так.
Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД.
В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.
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: максимум информации при минимальных потерях / Све...Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 17:00
Тезисы:
http://backendconf.ru/2017/abstracts/2777.html
В сложной ситуации хорошо иметь под рукой детали: сообщения об ошибках, статистику времени выполнения запросов, данные о производительности операционной системы и железа. Много деталей! Современные версии MySQL позволяют собрать информацию практически обо всём. Однако любой включённый мониторинг имеет свою цену: производительность. Именно поэтому универсального решения "всё включено", подходящего для любого MySQL-приложения, не существует. Даже при использовании инструментов с графическим интерфейсом у вас всегда есть выбор: что отслеживать и что нет.
В докладе я хочу обсудить, какие опции должны быть включены всегда, какие опциональны и при каких обстоятельствах их включать. Мы рассмотрим встроенные возможности MySQL, Percona-серверов и внешние решения.
SQL-ник DevDay. Рубцов. Новое в Percona Server и MariaDB в сравнении с MySQL 5.5DevDay
Григорий Рубцов — руководитель проектов SQLinfo.ru (http://sqlinfo.ru/) и Webew.ru (http://webew.ru/), автор онлайн-курса по MySQL (http://sqlinfo.ru/classes/) и спикер конференции РИТ++.
Новое в Percona Server и MariaDB в сравнении с MySQL 5.5
Обзор возможностей:
— новое для разработчика;
— новое для администратора;
— улучшения производительности;
— миграция и вопросы совместимости.
Технические детали:
— хранилище XtraDB;
— Percona Tools;
— алгоритмы оптимизации подзапросов в MariaDB.
Кластеры баз данных делаем сложные вещи просто / Андрей Тихонов (Avito)Ontico
Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?
Во-первых, если вы увеличиваете количество бэкенд-серверов, и, соответственно, количество рабочих процессов, то с ростом количества одновременных клиентских подключений вырастают и накладные расходы на базах данных.
Во-вторых, достаточно быстро может кончиться ресурс in-memory баз данных. Потребуется создать (либо увеличить) кластер, а это каждый раз влечёт за собой необходимость модифицировать логику приложения.
В-третьих, чем больше серверов, тем больше вероятность, что один из них выйдет из строя. Поэтому неплохо задуматься о том, как обеспечить отказоустойчивость, а это, опять же, потребует модифицировать логику приложения.
В этом докладе я расскажу, как и какими инструментами можно легко решить все вышеперечисленные проблемы: уменьшить накладные расходы от большого количества подключений к базам данных, создать/модифицировать кластер БД прозрачно для приложения, а также прозрачно добавить устойчивость к падениям серверов БД.
План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказо�
Современному хайлоду - современные решения: MySQL 8.0 и улучшения PerconaSveta Smirnova
MySQL всегда использовали под высокой нагрузкой. Недаром эта база была и остаётся самым популярным бэкэндом для web. Однако наши представления о хайлоде с каждым годом расширяются. Большая скорость передачи данных -> больше устройств с подключением к интернет -> больше пользователей -> больше данных.
Задачи, стоящие перед разработчиками MySQL, с каждым годом усложняются.
В этом докладе я расскажу как менялись сценарии использования MySQL за [почти] 25 лет её истории и что делали инженеры, чтобы MySQL оставалась актуальной. Мы затронем такие темы, как работа с большим количеством активных соединений и высокими объёмами данных. Я покажу насколько современные версии лучше справляются с возросшими нагрузками.
Я надеюсь, что после моего доклада те слушатели, которые используют старые версии, захотят обновиться и те, кто уже обновились, узнают как использовать современный MySQL на полную мощность.
Прочитана на конференции OST 2020: https://ostconf.com/materials/2857#2857
Доклад для XP Days Kiev 2013
"I will share our experience of development heavy enterprise database code with Agile methods using LiquiBase. We will meet pitfalls like Pl/Sql, Advanced MQ, triggers, database links, partitioned tables etc. Can really this stuff be developed with Agile process? Sure! I will show how we do it with LiquiBase, CI and TDD."
DevConf 2016
"Производительность MySQL: что нового?", Алексей Копытов
Алексей Копытов — разработчик MySQL и связанных с ним проектов с 2004г. Работал в компаниях MySQL AB, Sun Microsystems и Oracle. В компании Percona участвовал в разработке Percona Server, XtraBackup и XtraDB Cluster. В настоящее время занимается проблемами производительности MySQL на современном оборудовании.
MySQL 5.7 предлагает огромное количество улучшений в производительности практически всех компонентов: InnoDB, секционирования, бэкапов, репликации, DDL и оптимизаторе запросов.
В этом докладе мы рассмотрим эти оптимизации подробно, а также поговорим о проблемах, которые остаются актуальными до сих пор, возможных методах их решения и планируемых дальнейших оптимизациях в MySQL 8.
Similar to Эффективная отладка репликации MySQL (20)
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.
MySQL Cookbook 4th edition was released this summer. We are the book's authors and will show you how to "cook" MySQL. We will show you a few tasks with different priorities, such as JSON in MySQL for those who need flexibility, modern SQL for analytics, and Group Replication for high availability. We will also show how to write programs using JavaScript and Python languages, X DevAPI, and MySQL Shell. We will touch on some of the exciting features of MySQL Spatial Indexes and Geographical Data, Using a Full-Text Search, and more. We're hoping this talk will be interesting for both developers and administrators of MySQL.
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, и надеюсь, что вы тоже полюбите этот инструмент.
These slides are for my talk at Percona Live 2022: https://sched.co/10KEo
MySQL Cookbook 4th edition (https://www.target.com/p/mysql-cookbook-4th-edition-by-sveta-smirnova-alkin-tezuysal-paperback/-/A-85851771) is planned to be released this spring. I am one of the authors of the book and will show you how to "cook" MySQL. I will show you a few tasks with different priorities, such as JSON in MySQL for those who need flexibility; modern SQL for analytics, and Group Replication for high availability. I will also show how to write programs using JavaScript and Python languages, X DevAPI, and MySQL Shell. I expect this talk will be interesting for MySQL application developers.
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.
Talk for the DevOps Pro Moscow 2021: https://www.devopspro.ru/Sveta-Smirnova/
Производительность MySQL можно улучшить при помощи оптимизации запросов, настроек MySQL сервера и железа. Традиционно эти задачи распределялись между тремя ролями: Разработчик, Администратор баз данных и Системный Администратор. Теперь же все эти задачи решает DevOps, что непросто для одного человека. В этом докладе я расскажу об основных оптимизациях, которые решают большинство проблем производительности MySQL. Для иллюстраций я буду использовать реальные пользовательские истории и Percona Kubernetes Operator.
MySQL performance can be improved by tuning queries, server options, and hardware. Traditionally it was an area of responsibility of 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 focus on the single product is hard to gain when you focus on more than one. This is why I am doing this session. I will show minimal, but the most effective, set of options which will improve MySQL performance. For illustrations, I will use real user stories, gained by my Support experience, and Kubernetes operators, now available from all main MySQL eco-system vendors: Oracle, MariaDB, and Percona.
Presented at Open Source Summit Europe 2020: https://sched.co/eCGf
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
Galera Cluster for MySQL is a 100% synchronized cluster in regards to data modification operations (DML). It is ensured by the optimistic locking model and ability to rollback a transaction, which cannot be applied on all nodes. However, schema changes (DDL operations) are not transactional in MySQL, which adds complexity when you need to perform an upgrade or change schema of the database.
Changes made by DDL may affect results of the queries. Therefore all modifications must replicate on all nodes prior next data access. For operations which run momentarily it can be easily achieved, but schema changes may take hours to apply. Therefore in addition to safest synchronous blocking schema upgrade method TOI Galera also supports more relaxed, thought not safe, method RSU.
In her talk Sveta will describe which pitfalls you can hit while performing the change using one or another method, why and how to avoid them.
Presented at MariaDB Day Brussels 0202 2020: https://mariadb.org/mariadb-day-brussels-0202-2020-provisional-schedule/
How Safe is Asynchronous Master-Master Setup?Sveta Smirnova
It is common knowledge that built-in asynchronous master-master (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 master-master 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.
Presented in "MySQL, MariaDB and Friends devroom" at Fosdem in 2020: https://fosdem.org/2020/schedule/event/mysql_master_master/
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
2. ∙
Инженер тех. поддержки MySQL
∙ Автор
∙ MySQL Troubleshooting
∙ JSON UDF функции
∙ FILTER clause для MySQL
∙ Докладчик
∙ Percona Live, OOW, Fosdem,
DevConf, ...
Света Смирнова
2
19. Мастер
Получает изменение
Передаёт движку ->
Пишет в binary log
Синхронизируется ->
Табличный движок
Пишет в таблицу
<- Передаёт управление
<- Синхронизируется
Логическая
7
21. IO thread
Читает с мастера
Сохраняет в relay log
SQL thread
Два типа потоков
8
22. IO thread
Читает с мастера
Сохраняет в relay log
SQL thread
<- Читает из relay log
Два типа потоков
8
23. IO thread
Читает с мастера
Сохраняет в relay log
SQL thread
<- Читает из relay log
Исполняет
Два типа потоков
8
24. ∙ В 5.6+ SQL thread-ов может быть много
Несколько SQL-потоков
9
25. ∙ В 5.6+ SQL thread-ов может быть много
∙ С точки зрения отладки
∙ IO thread один
Несколько SQL-потоков
9
26. ∙ В 5.6+ SQL thread-ов может быть много
∙ С точки зрения отладки
∙ IO thread один
∙ Relay log один
Несколько SQL-потоков
9
27. ∙ В 5.6+ SQL thread-ов может быть много
∙ С точки зрения отладки
∙ IO thread один
∙ Relay log один
∙
Может отставать от мастера
Несколько SQL-потоков
9
28. ∙ В 5.6+ SQL thread-ов может быть много
∙ С точки зрения отладки
∙ IO thread один
∙ Relay log один
∙
Может отставать от мастера
∙ Ошибка одного потока останавливает все
Несколько SQL-потоков
9
29. ∙ В 5.7+ может быть несколько мастеров
Несколько мастеров (Multi-channel)
10
30. ∙ В 5.7+ может быть несколько мастеров
∙ С точки зрения отладки
∙
Несколько наборов relay log
Несколько мастеров (Multi-channel)
10
31. ∙ В 5.7+ может быть несколько мастеров
∙ С точки зрения отладки
∙
Несколько наборов relay log
∙ Несколько IO thread-ов
Несколько мастеров (Multi-channel)
10
32. ∙ В 5.7+ может быть несколько мастеров
∙ С точки зрения отладки
∙
Несколько наборов relay log
∙ Несколько IO thread-ов
∙ Несколько SQL thread-ов
Несколько мастеров (Multi-channel)
10
33. ∙ В 5.7+ может быть несколько мастеров
∙ С точки зрения отладки
∙
Несколько наборов relay log
∙ Несколько IO thread-ов
∙ Несколько SQL thread-ов
∙ slave_parallel_workers для каждого канала
Несколько мастеров (Multi-channel)
10
34. ∙ В 5.7+ может быть несколько мастеров
∙ С точки зрения отладки
∙
Несколько наборов relay log
∙ Несколько IO thread-ов
∙ Несколько SQL thread-ов
∙ slave_parallel_workers для каждого канала
∙
Каналы независимые
Несколько мастеров (Multi-channel)
10
35. ∙ В 5.7+ может быть несколько мастеров
∙ С точки зрения отладки
∙
Несколько наборов relay log
∙ Несколько IO thread-ов
∙ Несколько SQL thread-ов
∙ slave_parallel_workers для каждого канала
∙
Каналы независимые
∙ Ошибка на одном остановит только его
Несколько мастеров (Multi-channel)
10
36. ∙ В 5.7+ может быть несколько мастеров
∙ С точки зрения отладки
∙
Несколько наборов relay log
∙ Несколько IO thread-ов
∙ Несколько SQL thread-ов
∙ slave_parallel_workers для каждого канала
∙
Каналы независимые
∙ Ошибка на одном остановит только его
∙ Одноимённые объекты могут вызвать
конфликты
Несколько мастеров (Multi-channel)
10
38. ∙ Необходимо указать
∙
Название master’s binary log file
∙ Позицию
∙ С точки зрения отладки
∙
Событие выполняется по указателю позиции
Позиционная
11
39. ∙ Необходимо указать
∙
Название master’s binary log file
∙ Позицию
∙ С точки зрения отладки
∙
Событие выполняется по указателю позиции
∙ Легко пропустить
Позиционная
11
40. ∙ Необходимо указать
∙
Название master’s binary log file
∙ Позицию
∙ С точки зрения отладки
∙
Событие выполняется по указателю позиции
∙ Легко пропустить
∙ Легко переместить указатель в прошлое
Позиционная
11
41. ∙ Необходимо указать
∙
Название master’s binary log file
∙ Позицию
∙ С точки зрения отладки
∙
Событие выполняется по указателю позиции
∙ Легко пропустить
∙ Легко переместить указатель в прошлое
∙ Нет проверок
Позиционная
11
42. ∙ Каждая транзакция получает номер: GTID
Глобальные идентификаторы транзакций (GTID)
12
43. ∙ Каждая транзакция получает номер: GTID
∙ AUTO_POSITION=1
Глобальные идентификаторы транзакций (GTID)
12
44. ∙ Каждая транзакция получает номер: GTID
∙ AUTO_POSITION=1
∙ Не нужно указывать binary log и позицию
Глобальные идентификаторы транзакций (GTID)
12
57. ∙ Лог ошибок
∙ На слейве
∙ SHOW SLAVE STATUS
∙
Таблицы в Performance Schema
∙ Системная база mysql
Основные инструменты
15
58. ∙ Лог ошибок
∙ На слейве
∙ На мастере
∙ SHOW MASTER STATUS
∙
SHOW BINLOG EVENTS
∙
mysqlbinlog
Основные инструменты
15
59. ∙ Лог ошибок
∙ На слейве
∙ На мастере
∙
Percona Toolkit
Основные инструменты
15
60. ∙ Лог ошибок
∙ На слейве
∙ На мастере
∙
Percona Toolkit
∙
MySQL Utilities
Основные инструменты
15
61. ∙
Всегда доступна, требует настройки
∙
Асинхронная
∙
Мастер
∙ Хранит все изменения в binary log
Два формата: ROW и STATEMENT
∙ Слейв
∙
IO thread реплицирует с мастера в relay log
∙ SQL thread исполняет обновления
Несколько SQL thread-ов в 5.6+
Несколько каналов (мастеров) в 5.7+
∙ GTID в 5.6+
Особенности репликации: итоги
16
71. ∙ SHOW SLAVE STATUS
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
...
Last_IO_Errno: 1045
Last_IO_Error: error connecting to master ’root@127.0.0.1:13000’ -
retry-time: 60 retries: 1
Last_SQL_Errno: 0
Last_SQL_Error:
...
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 160824 03:18:36
Last_SQL_Error_Timestamp:
Сеть
21
72. ∙ SHOW SLAVE STATUS
∙ P_S.replication_connection_status
mysql> select * from performance_schema.replication_connection_statusG
*************************** 1. row ***************************
CHANNEL_NAME:
GROUP_NAME:
SOURCE_UUID:
THREAD_ID: NULL
SERVICE_STATE: CONNECTING
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET:
LAST_ERROR_NUMBER: 1045
LAST_ERROR_MESSAGE: error connecting to master ’root@127.0.0.1:13000’ -
retry-time: 60 retries: 4
LAST_ERROR_TIMESTAMP: 2016-08-24 03:21:36
1 row in set (0,01 sec)
Сеть
21
73. ∙ SHOW SLAVE STATUS
∙ P_S.replication_connection_status
∙ Error log
2016-08-24T00:18:36.077384Z 3 [ERROR] Slave I/O for channel ”: error connecting to
master ’root@127.0.0.1:13000’ - retry-time: 60 retries: 1, Error_code: 1045
2016-08-24T00:19:36.299011Z 3 [ERROR] Slave I/O for channel ”: error connecting to
master ’root@127.0.0.1:13000’ - retry-time: 60 retries: 2, Error_code: 1045
2016-08-24T00:20:36.485315Z 3 [ERROR] Slave I/O for channel ”: error connecting to
master ’root@127.0.0.1:13000’ - retry-time: 60 retries: 3, Error_code: 1045
2016-08-24T00:21:36.677915Z 3 [ERROR] Slave I/O for channel ”: error connecting to
master ’root@127.0.0.1:13000’ - retry-time: 60 retries: 4, Error_code: 1045
2016-08-24T00:22:36.872066Z 3 [ERROR] Slave I/O for channel ”: error connecting to
master ’root@127.0.0.1:13000’ - retry-time: 60 retries: 5, Error_code: 1045
Сеть
21
74. ∙ SHOW SLAVE STATUS
∙ P_S.replication_connection_status
∙ Error log
∙
Доступ
$ perror 1045
MySQL error code 1045 (ER_ACCESS_DENIED_ERROR): Access denied for user ’%-.48s’@’%-.64s’
(using password: %s)
Сеть
21
75. ∙ SHOW SLAVE STATUS
∙ P_S.replication_connection_status
∙ Error log
∙
Доступ
∙ MySQL клиент и логин-пароль слейва
$ mysql -h127.0.0.1 -P13000 -uroot -pbar
Warning: Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user ’root’@’localhost’ (using password: YES)
Сеть
21
76. ∙ SHOW SLAVE STATUS
∙ P_S.replication_connection_status
∙ Error log
∙
Доступ
∙ MySQL клиент и логин-пароль слейва
SHOW GRANTS
mysql> SHOW GRANTS;
+----------------------------------+
| Grants for foo@% |
+----------------------------------+
| GRANT SELECT ON *.* TO ’foo’@’%’ |
+----------------------------------+
Сеть
21
77. ∙ SHOW SLAVE STATUS
∙ P_S.replication_connection_status
∙ Error log
∙
Доступ
∙ MySQL клиент и логин-пароль слейва
SHOW GRANTS
∙
Исправьте привилегии на мастере
∙ Перезапустите репликацию
Сеть
21
78. ∙ Обычные методы отладки
∙ Проверьте с клиентом командной строки
∙ См. также Troubleshooting hardware resource
usage webinar
Производительность
22
80. ∙ Один мастер-один слейв
∙ Разные данные
Слейв не может выполнить event из relay log
∙ Разные ошибки на мастере и слейве
∙
Слейв сильно отстаёт от мастера
SQL thread: типичные проблемы
24
81. ∙ Один мастер-один слейв
∙ Разные данные
Слейв не может выполнить event из relay log
∙ Разные ошибки на мастере и слейве
∙
Слейв сильно отстаёт от мастера
∙ Круговая репликация и другая запись в
дополнение к SQL thread
∙ Разные данные
SQL thread: типичные проблемы
24
82. ∙ Таблица менялась вне репликации?
∙ Как?
∙
Конфликт с обновлениями на мастере?
Разные данные
25
83. ∙ Таблица менялась вне репликации?
∙ Идентична ли структура таблиц?
∙ Percona Toolkit
pt-table-checksum, pt-table-sync
∙ MySQL Utilities
mysqlrplsync, mysqldbcompare, mysqldiff
Разные данные
25
84. ∙ Таблица менялась вне репликации?
∙ Идентична ли структура таблиц?
∙ Обновления в неправильном порядке?
∙ mysqlbinlog
∙
Логика приложения на мастере
Разные данные
25
85. ∙ Только при использовании SBR
Обновления в неправильном порядке
26
86. ∙ Только при использовании SBR
∙ Блокировки на уровне строк
Обновления в неправильном порядке
26
87. ∙ Только при использовании SBR
∙ Блокировки на уровне строк
∙ Триггеры
∙ SET GLOBAL slave_skip_counter – No GTIDs!
∙
Пропустите транзакцию – GTIDs
∙
Синхронизируйте таблицы!
Обновления в неправильном порядке
26
88. ∙ Только при использовании SBR
∙ Блокировки на уровне строк
∙ Триггеры
∙
Разные опции: для олдфагов
∙ Запустите слейв с опциями мастера
∙ Перезапустите SQL thread
∙
Исправлено в последних версиях
Обновления в неправильном порядке
26
89. ∙
Потоки
∙ Мастер выполняет обновления в несколько
потоков
∙
Слейв использует один
Слейв отстаёт от мастера
27
91. ∙
Потоки
∙
Seconds_behind_master увеличивается –
Нельзя однозначно полагаться!
∙ Настройте производительность слейва
∙ Multi-threaded слейв
Один поток на одну базу в 5.6
Могут возникнуть проблемы параллельного выполнения между потоками слейва
Слейв отстаёт от мастера
27
92. ∙
Потоки
∙
Seconds_behind_master увеличивается –
Нельзя однозначно полагаться!
∙ Настройте производительность слейва
∙ Multi-threaded слейв
Один поток на одну базу в 5.6
Могут возникнуть проблемы параллельного выполнения между потоками слейва
∙ Индексы на слейве
Имеет смысл только для SBR
Слейв отстаёт от мастера
27
94. ∙ Единственный relay log
∙
Скорость в высококонкурентной среде может
быть меньше, чем у мастера
Производительность
29
95. ∙ Единственный relay log
∙
Скорость в высококонкурентной среде может
быть меньше, чем у мастера
∙ slave_parallel_workers
Производительность
29
96. ∙ Единственный relay log
∙
Скорость в высококонкурентной среде может
быть меньше, чем у мастера
∙ slave_parallel_workers
∙ slave_parallel_type=DATABASE |
LOGICAL_CLOCK
Производительность
29
97. ∙
Те же методы, что и для однопоточного
Неправильное поведение
30
98. ∙
Те же методы, что и для однопоточного
∙
Ошибка одного thread-а останавливает все
mysql> select WORKER_ID, SERVICE_STATE, LAST_SEEN_TRANSACTION, LAST_ERROR_NUMBER,
-> LAST_ERROR_MESSAGE from performance_schema.replication_applier_status_by_workerG
*************************** 1. row ***************************
WORKER_ID: 1
SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: d318bc17-66dc-11e6-a471-30b5c2208a0f:4988
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
*************************** 2. row ***************************
WORKER_ID: 3
SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: d318bc17-66dc-11e6-a471-30b5c2208a0f:4986
LAST_ERROR_NUMBER: 1032
LAST_ERROR_MESSAGE: Worker 2 failed executing transaction...
Неправильное поведение
30
101. ∙ Репликация должна быть настроена для
каждого канала
∙
Можно одновременно использовать мастера
с GTID и без
Особенности
32
102. ∙ Репликация должна быть настроена для
каждого канала
∙
Можно одновременно использовать мастера
с GTID и без
∙ Те же проблемы и решения, что и в случае
обычной репликации
Особенности
32
103. ∙ Репликация должна быть настроена для
каждого канала
∙
Можно одновременно использовать мастера
с GTID и без
∙ Те же проблемы и решения, что и в случае
обычной репликации
∙ Фильтры применяются одновременно для
всех каналов
Особенности
32
105. ∙ Проблемы мастера
∙ Те же, что и для обычного сервера
∙
Больше пишет и проверяет
Итоги
34
106. ∙ Проблемы мастера
∙ Slave IO thread
∙ Обычные проблемы с сетью
∙
mysql command line client для тестов
Итоги
34
107. ∙ Проблемы мастера
∙ Slave IO thread
∙ Slave SQL thread
∙ Обычные проблемы при выполнении запросов
∙
Обычные проблемы движка
∙
Меньше потоков выполнения, чем на мастере
Итоги
34
108. ∙
Basic Techniques – troubleshooting webinar
∙
Troubleshooting hardware resource usage
webinar
∙ Introduction into storage engine
troubleshooting webinar
∙ Percona Toolkit
∙ MySQL Utilities
∙
Книга MySQL High Availability
∙
MySQL Replication Team blog
Больше информации
35
113. ∙ Актуальны ли данные?
∙ Одинаковы ли
∙
Структура таблиц
∙ Движок
∙ Данные
∙
Любая запись может сломать репликацию
Асинхронная: вопросы на слейве
40
114. ∙ Запись на мастере медленнее асинхронной
репликации
Полусинхронная: с точки зрения отладки
41
115. ∙ Запись на мастере медленнее асинхронной
репликации
∙
Сколько "Ack"-ов ждёт мастер?
Полусинхронная: с точки зрения отладки
41
116. ∙ Запись на мастере медленнее асинхронной
репликации
∙
Сколько "Ack"-ов ждёт мастер?
∙ До версии 5.7: от одного слейва
Полусинхронная: с точки зрения отладки
41
117. ∙ Запись на мастере медленнее асинхронной
репликации
∙
Сколько "Ack"-ов ждёт мастер?
∙ До версии 5.7: от одного слейва
∙ Сейчас:
rpl_semi_sync_master_wait_for_slave_count
Полусинхронная: с точки зрения отладки
41
118. ∙ Запись на мастере медленнее асинхронной
репликации
∙
Сколько "Ack"-ов ждёт мастер?
∙ До версии 5.7: от одного слейва
∙ Сейчас:
rpl_semi_sync_master_wait_for_slave_count
∙ Остальных ждать не будет
Полусинхронная: с точки зрения отладки
41
119. ∙ Запись на мастере медленнее асинхронной
репликации
∙
Сколько "Ack"-ов ждёт мастер?
∙
Что значит "Ack"?
Полусинхронная: с точки зрения отладки
41
120. ∙ Запись на мастере медленнее асинхронной
репликации
∙
Сколько "Ack"-ов ждёт мастер?
∙
Что значит "Ack"?
∙ Событие записано в relay log
Полусинхронная: с точки зрения отладки
41
121. ∙ Запись на мастере медленнее асинхронной
репликации
∙
Сколько "Ack"-ов ждёт мастер?
∙
Что значит "Ack"?
∙ Событие записано в relay log
∙ Неизвестно, выполнено ли оно
Полусинхронная: с точки зрения отладки
41
122. ∙ Запись на мастере медленнее асинхронной
репликации
∙
Сколько "Ack"-ов ждёт мастер?
∙
Что значит "Ack"?
∙ Что происходит при timeout-е?
Полусинхронная: с точки зрения отладки
41
123. ∙ Запись на мастере медленнее асинхронной
репликации
∙
Сколько "Ack"-ов ждёт мастер?
∙
Что значит "Ack"?
∙ Что происходит при timeout-е?
∙ Репликация становится асинхронной
Полусинхронная: с точки зрения отладки
41
125. ∙
Каждое изменение записывается дважды:
Файлы движка:
логи, данные, ...
Бинарный лог
∙
Можно параллельно писать на слейве
Логическая: с точки зрения отладки
42
126. ∙ Не существует в MySQL!
Для сравнения: физическая репликация
43
127. ∙ Не существует в MySQL!
∙ Есть две закрытые реализации
Для сравнения: физическая репликация
43
128. ∙ Не существует в MySQL!
∙ Мастер пишет только в файлы движка
Для сравнения: физическая репликация
43
129. ∙ Не существует в MySQL!
∙ Мастер пишет только в файлы движка
∙ Которые реплицируются на слейв
Для сравнения: физическая репликация
43
130. ∙ Не существует в MySQL!
∙ Мастер пишет только в файлы движка
∙ Которые реплицируются на слейв
∙ С точки зрения отладки
∙
IO: изменения записываются единожды
∙ Нельзя параллельно писать на слейве
∙ Любое несоответствие данных приводит к
поломке
Для сравнения: физическая репликация
43
132. ∙ Гарантия, что транзакция не будет
выполнена дважды
GTID: с точки зрения отладки
45
133. ∙ Гарантия, что транзакция не будет
выполнена дважды
∙
Простой failover
GTID: с точки зрения отладки
45
134. ∙ Гарантия, что транзакция не будет
выполнена дважды
∙
Простой failover
∙ Пропустить одну транзакцию непросто
GTID: с точки зрения отладки
45
135. ∙ Гарантия, что транзакция не будет
выполнена дважды
∙
Простой failover
∙ Пропустить одну транзакцию непросто
∙
Используйте mysqlslavetrx
GTID: с точки зрения отладки
45
136. ∙ Гарантия, что транзакция не будет
выполнена дважды
∙
Простой failover
∙ Пропустить одну транзакцию непросто
∙
Используйте mysqlslavetrx
∙ Осторожнее с настройкой expire_logs_days!
GTID: с точки зрения отладки
45
138. ∙ Statement-based (SBR)
∙ Запросы записываются в оригинальном виде
∙
Риск несовпадения данных (non-safe)
INSERT IGNORE
LIMIT без ORDER BY
Non-deterministic функции
...
Форматы Binary log
46
139. ∙ Statement-based (SBR)
∙ Row-based (RBR)
∙ Обычно пишется больше данных
IO
Скорость передачи
binlog_row_image
Форматы Binary log
46
140. ∙ Statement-based (SBR)
∙ Row-based (RBR)
∙ Обычно пишется больше данных
IO
Скорость передачи
binlog_row_image
∙ Ухудшение производительности для таблиц
без первичного (уникального) ключа
Форматы Binary log
46
144. ∙ Информация о старте слейва
∙ Ошибки
2016-08-23T12:11:21.867440Z 4 [ERROR] Slave SQL for channel ’master-1’: Could not execute
Update_rows event on table m2.t1; Can’t find record in ’t1’, Error_code: 1032; handler error
HA_ERR_END_OF_FILE; the event’s master log master-bin.000001, end_log_pos 1213, Error_code: 1032
2016-08-23T12:11:21.867471Z 4 [Warning] Slave: Can’t find record in ’t1’ Error_code: 1032
2016-08-23T12:11:21.867484Z 4 [ERROR] Error running query, slave SQL thread aborted.
Fix the problem, and restart the slave SQL thread with "SLAVE START".
We stopped at log ’master-bin.000001’ position 989
Лог ошибок
48
145. ∙ Информация о старте слейва
∙ Ошибки
∙ Остановка слейва
Лог ошибок
48
146. Вся информация о слейве
∙
Конфигурация IO thread
∙ Конфигурация SQL thread
∙ Статус IO thread
∙ Статус SQL thread
∙ Ошибки
Только последняя
Все есть в логе ошибок
SHOW SLAVE STATUS
49
147. mysql> show slave status G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 127.0.0.1
...
Master_Log_File: master-bin.000002
Read_Master_Log_Pos: 63810611
Relay_Log_File: slave-relay-bin-master@002d1.000004
Relay_Log_Pos: 1156
Relay_Master_Log_File: master-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: No
...
Replicate_Wild_Ignore_Table:
Last_Errno: 1032
Last_Error: Could not execute Update_rows event on table m2.t1; Can’t find
record in ’t1’, Error_code: 1032; handler error HA_ERR_END_OF_FILE;
the event’s master log master-bin.000001, end_log_pos 1213
Skip_Counter: 0
...
SHOW SLAVE STATUS
49
148. ∙ Не нужно парсить вывод SHOW
Таблицы в Performance Schema
50
149. ∙ Не нужно парсить вывод SHOW
∙ Конфигурация
∙
replication_connection_configuration
∙ replication_applier_configuration
∙ mysql> select * from replication_connection_configuration
-> join replication_applier_configuration using(channel_name);
Таблицы в Performance Schema
50
150. ∙ Не нужно парсить вывод SHOW
∙ Конфигурация
∙ Статус IO thread
∙ replication_connection_status
Таблицы в Performance Schema
50
151. ∙ Не нужно парсить вывод SHOW
∙ Конфигурация
∙ Статус IO thread
∙ Статус SQL thread
∙
replication_applier_status
∙ replication_applier_status_by_coordinator - MTS!
mysql> select * from replication_applier_status join
-> replication_applier_status_by_coordinator
-> using(channel_name);
Таблицы в Performance Schema
50
152. ∙ Не нужно парсить вывод SHOW
∙ Конфигурация
∙ Статус IO thread
∙ Статус SQL thread
∙
replication_applier_status
∙ replication_applier_status_by_worker
mysql> select * from replication_applier_status join
-> replication_applier_status_by_worker
-> using(channel_name);
Таблицы в Performance Schema
50
153. ∙ Master Info
mysql> select * from slave_master_infoG
*************************** 1. row ***************************
Number_of_lines: 25
Master_log_name: mysqld-bin.000001
Master_log_pos: 154
Host: 127.0.0.1
User_name: root
User_password: secret
Port: 13000
Connect_retry: 60
Enabled_ssl: 0
...
Uuid: 31ed7c8f-74ea-11e6-8de8-30b5c2208a0f
Retry_count: 86400
...
Enabled_auto_position: 1
...
Системная база mysql: только на слейве
51
154. ∙ Master Info
∙ Relay log info
mysql> select * from slave_relay_log_infoG
*************************** 1. row ***************************
Number_of_lines: 7
Relay_log_name: ./slave-relay-bin-master@002d1.000004
Relay_log_pos: 1156
Master_log_name: master-bin.000001
Master_log_pos: 989
Sql_delay: 0
Number_of_workers: 0
Id: 1
Channel_name: master-1
Системная база mysql: только на слейве
51
155. ∙ Master Info
∙ Relay log info
∙ Worker info: multi-threaded slave
mysql> select * from slave_worker_infoG
*************************** 1. row ***************************
Id: 1
...
*************************** 8. row ***************************
Id: 8
Relay_log_name: ./Thinkie-relay-bin.000004
Relay_log_pos: 1216
Master_log_name: mysqld-bin.000001
Master_log_pos: 1342
Checkpoint_relay_log_name: ./Thinkie-relay-bin.000004
Checkpoint_relay_log_pos: 963
Checkpoint_master_log_name: mysqld-bin.000001
Системная база mysql: только на слейве
51
156. mysql> show master statusG
*************************** 1. row ***************************
File: master-bin.000005
Position: 154
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0,00 sec)
SHOW MASTER STATUS
52
161. ∙ Percona Toolkit
∙ pt-table-checksum
Проверяет соответствие данных
∙ pt-table-sync
Исправляет несоответствия в данных
Тулкиты
56
162. ∙ Percona Toolkit
∙ pt-table-checksum
Проверяет соответствие данных
∙ pt-table-sync
Исправляет несоответствия в данных
∙ pt-slave-find
Показывает топологию
Тулкиты
56
163. ∙ MySQL Utilities
∙ mysqlrplcheck
Проверяет, можно ли запустить репликацию
Тулкиты
56
164. ∙ MySQL Utilities
∙ mysqlrplcheck
Проверяет, можно ли запустить репликацию
∙ mysqlrplshow
Показывает топологию
Тулкиты
56
165. ∙ MySQL Utilities
∙ mysqlrplcheck
Проверяет, можно ли запустить репликацию
∙ mysqlrplshow
Показывает топологию
∙ mysqlrplsync
Проверяет соответствие данных
Тулкиты
56
166. ∙ MySQL Utilities
∙ mysqlrplcheck
Проверяет, можно ли запустить репликацию
∙ mysqlrplshow
Показывает топологию
∙ mysqlrplsync
Проверяет соответствие данных
∙ mysqlslavetrx
Пропускает 1-N транзакций
Тулкиты
56
169. ∙ MySQL Utilities
∙
mysqldbcompare
Сравнивает две базы данных
∙
mysqldiff
Сравнивает определения объектов
∙
mysqlserverinfo
Показывает основные опции, такие как port и datadir
Ориентирован на репликацию
Тулкиты
56
170. ∙
Лог ошибок
∙ Слейв
∙ SHOW SLAVE STATUS
∙
Таблицы в Performance Schema
∙
Таблицы в mysql database
∙ Мастер
∙ SHOW MASTER STATUS
∙
SHOW BINLOG EVENTS
∙ mysqlbinlog
∙ mysql command line client
Основные инструменты: итоги
57