percona server что это

Форки движка MySQL: MariaDB, Percona. who is who?

MySQL стал собственностью Oracle, есть ли альтернативы и как быстро движение вперед. Вроде как обобщающего обзорчика «who is who?» еще не было. Итак, обзорчик для тех кто «не в теме»

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

Майкл Видениус (Michael Widenius), основатель MySQL и основатель компании MySQL AB (которую и поглотила Sun, которую и поглотила Oracle)
Петр Зайцев — эксперт по производительности MySQL, бывший тимлидер группы High Perfomance в MySQL Inc, ведущий блога MySQLPerformanceBlog.com

Итак, какие существуют альтернативы?

Percona server — это сборка MySQL (от Петра Зайцева и ко) с включенным по умолчанию XtraDB storage engine. Отличается от MySQL+InnoDB plugin лучшей производительностью/масштабируемостью, особенно на современных многоядерных серверах. Также улучшена функциональность — больше всякой полезной для оптимизации статистики и пр. Собирается в вариантах базирующихся на MySQL 5.0 и 5.1. Полностью совместим с таблицами innodb, то есть можно переходить от innodb к xtradb и обратно без проблем (если не использовать некоторые специфичные для xtradb функции, типа меньшего размера страницы).

Хранилище XtraDB основано на коде InnoDB-plugin, полностью совместимо с ним, но отличающийся заметно более высокой производительностью, благодаря интеграции патчей от компаний Google и Percona. В частности, в XtraDB улучшен механизм работы с памятью, улучшена работа подсистемы ввода/вывода InnoDB, добавлена поддержка нескольких потоков чтения и записи, поддержка управления пропускной способностью, реализация упреждающей выборкой данных (read-ahead), адаптивная установка контрольных точек (adaptive checkpointing), расширены возможности по масштабированию для больших проектов, система организации блокировок адаптирована для работы на системах с большим числом CPU, добавлены дополнительные возможности для накопления и анализа статистик

Источник

percona server что это. Смотреть фото percona server что это. Смотреть картинку percona server что это. Картинка про percona server что это. Фото percona server что это percona server что это. Смотреть фото percona server что это. Смотреть картинку percona server что это. Картинка про percona server что это. Фото percona server что это

Useful Links

Related Resources

Maximize application performance with our expert open source database support, managed services and consulting.

More enterprises rely on MySQL® performance, resilience and security to power the applications and websites that make achieving their business goals possible.

Percona Server for MySQL® is a free, fully compatible, enhanced and open source drop-in replacement for any MySQL database. It provides superior performance, scalability and instrumentation.

Percona Server for MySQL is trusted by thousands of enterprises to provide better performance and concurrency for their most demanding workloads, and delivers greater value to MySQL server users with optimized performance, greater performance scalability and availability, enhanced backups and increased visibility.

Originally, we used MariaDB to deliver v1 of MySQL for PCF, but found that for v2 Percona Server for MySQL remains more in line with Oracle’s delivery. Combined with the ability to provide responsive, knowledgeable support, we found Percona to be a better fit for our customer’s needs.

Supported by Percona Experts

Whether you’re running Percona Server for MySQL, MySQL Enterprise Edition, MySQL Community Edition, or some other MySQL fork, Percona offers a comprehensive, responsive, and cost-effective support, managed service or consulting plan to help your organization’s MySQL deployment succeed

Enterprise-Grade Features for Free

Percona Server for MySQL delivers extremely high-performance and reliability to more of the enterprises that drive businesses online.

Works on-premises and in the cloud

Percona Server for MySQL is fully compatible with today’s cloud providers such as AWS, Google Cloud, Microsoft Azure and others, fully deployed in the cloud or as a hybrid solution.

Enterprise ready

Percona Server for MySQL includes advanced, fully-enabled external authentication, audit logging and threadpool scalability features that are only available in Oracle’s commercial MySQL Enterprise Edition.

SaaS deployable

Increases flexibility for architectures such as co-located databases with hundreds of thousands of tables and heterogeneous backup and retention policies.

Vertical scalability and server consolidation

Scales to over 48 CPU cores, with the ability to achieve hundreds of thousands of I/O operations per second on high-end solid-state hardware.

Deep visibility into database performance

Detailed query logging with per-query statistics about locking, I/O and query plan, as well as performance and access counters per-table, per-index, per-user and per-host.

Percona Server for MySQL provides:

Percona Software Platform Solution

Percona Server for MySQL is part of a complete, integrated suite of Percona database solutions that provide better performance, reliability, diagnostics and lowers the total cost of ownership when used together. The Percona Software Platform and includes true non-blocking online backups, tight compression of data and extended instrumentation and tooling for quick diagnosis and resolution of issues.

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Percona Server

Содержание

Преимущества и возможности

Подсистема хранения Percona XtraDB

Percona XtraDB использует отказоустойчивый, надежный ACID-совместимый дизайн и продвинутую архитектуру MVCC от InnoDB и имеет богатый функционал, лучшую настраиваемость и масштабируемость. В частности, она призвана лучше масштабироваться на многоядерных системах, более эффективно использовать память и быть более удобной и полезной. Новые возможности данной подсистемы хранения были специально разработаны для преодоления некоторых ограничений InnoDB.

Percona XtraDB распространяется исключительно как часть Percona Server.

Сравнение Percona Server и MySQL

Persona Server имеет следующие преимущества [Источник 2] по сравнению со стандартным сервером базы данных MySQL:

ХарактеристикиPercona Server 5.7.10MySQL 5.7.10
Open sourceДаДа
ACID-совместимостьДаДа
Multi-Version Concurrency ControlДаДа
Блокировка строкДаДа
Автоматическое восстановление после сбояДаДа
Разметка таблицДаДа
ПросмотрыДаДа
ПодзапросыДаДа
ТриггерыДаДа
Хранимые процедурыДаДа
Внешние ключиДаДа
GTID-репликацииДаДа
Дополнительные функции для разработчиковPercona Server 5.7.10MySQL 5.7.10
NoSQL Soket-Level интерфейсДаДа
Дополнительные хэш\дайджест функцииДаНет
Дополнительные функции диагностикиPercona Server 5.7.10MySQL 5.7.10
Количество таблиц INFORMATION_SCHEMA7561
Количество глобальных счетчиков производительности и состояния385355
Счетчики производительности таблицДаНет
Счетчики производительности индексовДаНет
Счетчики производительности пользователейДаНет
Счетчики производительности клиентовДаНет
Счетчики производительности потоковДаНет
Глобальная статистика времени ответа на запросыДаНет
Усовершенствованная команда SHOW ENGINE INNODB STATUSДаНет
Откат информации о сегментахДаНет
Информация о временных таблицахДаНет
Улучшения производительности и масштабируемостиPercona Server 5.7.10MySQL 5.7.10
Улучшенная масштабируемость за счет разделения мьютексовДаНет
Улучшенная подсистема хранения MEMORYДаНет
Улучшенная очисткаДаНет
Дополнительные функции для администраторов и операционистовPercona Server 5.7.10MySQL 5.7.10
Настраиваемые размеры страницДаДа
Настраиваемое быстрое создание индексовДаНет
Отслеживание изменений страницыДаНет
PAM-аутентификацияДаТолько в версии Enterprise
Пул потоковДаТолько в версии Enterprise
Блокировка до резервного копированияДаНет
Расширенная команда SHOW GRANTSДаНет
Улучшенная система обработки поврежденных таблицДаНет
Возможность аннулирования простаивающих транзакцииДаНет
Улучшенная команда START TRANSACTION WITH CONSISTENT SNAPSHOTДаНет
Функции для работы с DBaaS (Database-as-a-service)Percona Server 5.7.10MySQL 5.7.10
Особая учетная запись Utility UserДаНет
Расширенные модификаторы программных опцийДаНет
Enforcing Storage EngineДаНет

Установка Percona Sever

Установка для Debian и Ubuntu

Установка из репозитория для apt

Установка с использованием загруженных deb-пакетов

Внимание: Перед установкой Percona Server данным способом убедитесь, что у вас установлены следующие необходимые пакеты: mysql-common, libjemalloc1, libaio1, libmecab2.

Установка для Red Hat Enterprise Linux и CentOS

Установка из репозитория для yum

Установка с использованием загруженных rpm-пакетов

Внимание: Перед установкой Percona Server данным способом убедитесь, что у Вас установлены все необходимые для его работы пакеты.

Работа c Percona Server

Percona Server по умолчанию хранит данные в каталоге /var/lib/mysql/. Файл с настройками, необходимыми для управления Percona Server, находится по следующему пути: /etc/mysql/my.cnf.

1. Запуск сервиса Чтобы произвести запуск сервиса, необходимо выполнить команду:

Примечание: Percona Server запускается автоматически после установки на Ubuntu и Debian, если в её процессе не возникали ошибки.

2. Проверка того, что сервис запущен Вы можете проверить статус работы сервиса, выполнив команду: 3. Остановка сервиса: 4. Перезапуск сервиса:

Примеры использования Percona Server

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

Пример 1

Пример 2

Удаление Percona Server

Чтобы полностью удалить Percona Server, Вам необходимо удалить все его установленные пакеты и пользовательские данные.

Удаление для Debian и Ubuntu

Удаление для Red Hat Enterprise Linux и CentOS

Percona Server на Ubuntu 18.04

Установка, пример использования и удаление Percona Server на Ubuntu 18.04:

Тесты производительности Percona Server

В марте 2016 года Алексеем Строгановым, Laurynas Biveinis и Вадимом Ткаченко было проведено тестирование Percona Server для анализа улучшений производительности. Несмотря на то, что MySQL 5.7 показал прогресс в различных аспектах масштабируемости и производительности, они обнаружили, что пределы рабочей нагрузки ввода-вывода возможно расширить еще больше.

На тот момент Percona Server 5.7.11 обладала для этого двумя главными функциями:

Результаты тестирования в Sysbench OLTP_RW

Ниже приведены настройки, используемые при тестировании:

Графики результатов тестирования изображены на рисунке 1.

percona server что это. Смотреть фото percona server что это. Смотреть картинку percona server что это. Картинка про percona server что это. Фото percona server что это

Рисунок 1 – Sysbench OLTP_RW, I/O scenario

Для понимания результатов тестирование было проведено дважды с двумя разными настройками InnoDB:

Для лучшего понимания деталей, рассмотрим результаты тестирования с 512 потоками, показанными на рисунке 2.

percona server что это. Смотреть фото percona server что это. Смотреть картинку percona server что это. Картинка про percona server что это. Фото percona server что это

Рисунок 2 – Sysbench OLTP_RW, 512 threads

На приведенных выше графиках видно, что конкуренция потоков из-за их большого числа существенно ухудшает пропускную способность, но на задержке это сказывается еще хуже. Ограничение числа одновременно обслуживаемых потоков улучшает ситуацию, но даже так Percona Server показывает на 15-25% лучшие результаты по сравнению с MySQL.

Ниже, на рисунке 3, можно наблюдать конфликтную ситуацию для каждого из приведенных выше тестов. Графики показывают общее накопленное время ожидания по всем потокам, приходящимся на различные объекты синхронизации (в секунду).

percona server что это. Смотреть фото percona server что это. Смотреть картинку percona server что это. Картинка про percona server что это. Фото percona server что это

Рисунок 3 – TOP 5 performance schema synch waits

Источник

Percona Server

Название базовой системы (платформы):MySQL
Разработчики:Percona
Дата последнего релиза:2016/02/24
Технологии:СУБД, Серверные платформы

14 октября 2013 года стало известно о выпуске компанией Percona версии СУБД Percona Server 5.6.

В новом релизе СУБД реализованы возможности масштабируемости, доступности, резервирования и безопасности, до недавнего времени свойственные лишь коммерческой версии MySQL 5.6 Enterprise Edition корпорации Oracle.

Percona Server справляется с тысячью параллельно работающих потоков (утверждают в компании)

2016: Percona Server for MySQL 5.7

Вышел также релиз свободного продукта Percona XtraBackup 2.4, предоставляющего средства для «горячего» резервирования MySQL и других вариантов этой СУБД, включая Percona Server и MariaDB. Percona Server и Percona XtraBackup доступны для бесплатной загрузки и распространяются под свободной лицензией GPL.

В составе Percona Server 5.7 все изменения, добавленные компанией Oracle в MySQL 5.7 Community Edition, и полностью совместим с этой СУБД. Версия от Percona предлагает расширенные возможности резервного копирования, мониторинга, оптимизированный к операциям записи движок TokuDB, обеспечивающий более высокую степень сжатия данных и эффективность работы в облаке. Percona Server для MySQL 5.7 также сохраняет курс на повышение производительности, улучшение масштабируемости и обеспечение высокой доступности.

Источник

Переход на Percona XtraDB Cluster. Одна из возможных конфигураций

Итак, я начал внедрять в своей организации Percona XtraDB Cluster — переводить базы данных с обычного MySQL сервера в кластерную архитектуру.

Коротко о задаче и вводные данные

Большинство проектов мы держим удаленно в ДЦ, поэтому и кластер будет находится там.
Задача разнести кластер географически по разным дата-центрам не стоит.

Для построения кластера используются 3 сервера одинаковой конфигурации: HP DL160 G6, 2X Xeon E5620, 24 GB RAM, 4x SAS 300GB в аппаратном RAID 10. Неплохое брендовое железо, которое я использую уже давно и которое меня пока не подводило.

Почему Percona?

— синхронная true multi-master репликация (Galera)
— возможность коммерческой поддержки от Percona
— форк MySQL c внушительным списком оптимизаций

Схема кластера

В кластере 3 ноды, для каждой вышеописанный физический сервер (OS Ubuntu 12.04).

Используется прозрачный коннект к одному виртуальному IP-адресу, разделяемому между всеми 3 серверами при помощи keepalived. Для балансировки нагрузки на ноды используется HAProxy, конечно же установленный на каждом сервере, чтобы в случае отказа одного из них, нагрузку благодаря VIP продолжал балансировать другой. Мы намеренно решили использовать для LB и VIP те же железки, что и для кластера.

Node A используется в качестве Reference (Backup) Node, которую не будут загружать запросами наши приложения. При этом она будет полноправным членом кластера, и участвовать в репликации. Это делается в связи с тем, что в случае сбоя в кластере или нарушения целостности данных мы будем иметь ноду, которая почти наверняка содержит наиболее консистентные данные, которые приложения просто не могли порушить из-за отсутствия доступа. Возможно, это выглядит расточительным расходованием ресурсов, но для нас 99% надежность данных все же важнее чем доступность 24/7. Именно эту ноду мы будем использовать для SST — State Snapshot Transfer — автоматического слива дампа на присоединяемую к кластеру новую ноду или поднимаемую после сбоя. Кроме того, Node A — отличный кандидат для сервера, откуда мы будем снимать стандартные периодические резервные копии.

Схематично это все можно изобразить примерно так:

percona server что это. Смотреть фото percona server что это. Смотреть картинку percona server что это. Картинка про percona server что это. Фото percona server что это
Node B и Node C это рабочие лошадки, которые держат нагрузку, но при этом операции записи берет на себя только одна из них. Такова рекомендация многих специалистов, и ниже я остановлюсь на этом вопросе подробно.

HAProxy и детали балансировки

Запросы, приходящие на порт 3306, HAProxy раскидывает по Round Robin между нодами B и C.
То, что приходит на 3307, проксируется только на Node B. При этом если Node B вдруг упадет, запросы перейдут на указанную в качестве резервной Node C.

Для реализации нашей идеи (писать только на одну из нод) приложения должны быть написаны так, чтобы запросы на чтение шли через соединение с 10.0.0.70:3306 (10.0.0.70 — наш VIP), а запросы на запись направлялись на 10.0.0.70:3307.

В нашем случае это потребует некоторой работы по созданию в конфиге PHP приложения нового коннекта, и замене имени переменной-DBHandler на другое значение. В целом, это не так сложно для тех приложений, которые написаны нами. Для сторонних проектов, чьи базы тоже будут в кластере, мы просто укажем порт 3307 по умолчанию. Нагрузку эти проекты создают небольшую, и потеря возможности распределенного чтения не так критична.

Конфиг HAProxy (/etc/haproxy/haproxy.cfg):

Для того, чтобы HAProxy мог определить жив ли узел кластера, используется утилита clustercheck, (входит в пакет percona-xtradb-cluster), которая выводит сведения о состоянии ноды (Synced / Not Synced) в виде HTTP ответа. На каждом из узлов должен быть настроен xinetd сервис:

HAProxy поднимает веб-сервер и предоставляет скрипт для просмотра статистики, что очень удобно для визуального мониторинга состояния кластера.
URL выглядит так: Порт, а также логин и пароль для Basic авторизации указываются в конфиге.

Keepalived и VIP

Конфигурация нод

На хабре уже есть статья об установке и тестировании PXC: habrahabr.ru/post/152969, где оба вопроса рассмотрены подробно, поэтому установку я опускаю. Но опишу конфигурирование.

В первую очередь, не забудьте синхронизировать время на всех нодах. Я упустил этот момент, и довольно долго не мог понять, почему у меня намертво подвисает SST — он начинался, висел в процессах, но по факту ничего не происходило.

my.cnf на Node A (в моих конфигах это node105):

Дальше — только отличающиеся параметры:

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

Именно на такой конфигурации я остановился сейчас, и собираюсь постепенно переводить проекты в кластер. Планирую продолжить писать о своем опыте и дальше.

Проблемные вопросы

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

Почему рекомендуется писать на одну ноду из всех доступных в кластере? Ведь казалось бы, это противоречит идее мульти-мастер репликации.

Когда я впервые увидел эту рекомендацию, то очень расстроился. Я представлял себе multi-master таким образом, что можно ни о чем не заботясь писать на любой узел, и изменения гарантированно применятся синхронно на всех нодах. Но суровые реалии жизни таковы, что при таком подходе возможно повление cluster-wide deadlocks. Особенно велика вероятность в случае параллельного изменения одних и тех же данных в длинных транзакциях. Т.к. я не являюсь пока экспертом в этом вопросе, не могу объяснить этот процесс на пальцах. Но есть хорошая статья, где эта проблема освещена подробнейшим образом: Percona XtraDB Cluster: Multi-node writing and Unexpected deadlocks

Мои собственные тесты показали, что при агрессивной записи на все ноды они ложились одна за другой, оставляя рабочей только Reference Node, т.е. по факту можно сказать, что кластер прекращал работу. Это, безусловно минус такой конфигурации, ведь третий узел мог бы в этом случае взять нагрузку на себя, но зато мы уверены, что данные там в целости и сохранности и в самом крайнем случае мы можем вручную запустить его в работу в режиме одиночного сервера.

Как правильно указать IP адреса существующих в кластере нод при подключении новой?

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

Значения этих директив поначалу у меня вызвали особую путаницу.
Дело в том, что многие мануалы советовали на первой ноде кластера оставлять пустое значение gcomm:// в wsrep_urls.
Оказалось, что это неправильно. Наличие gcomm:// означает инициализацию нового кластера. Поэтому сразу после старта первой ноды в ее конфиге нужно удалять это значение. В противном случае после рестарта этого узла вы получите два разных кластера, один из которых будет состоять только из первой ноды.

Для себя я вывел порядок конфигурации при запуске и перезапуске кластера (уже описанный выше более подробно)
1. Node A: запуск c gcomm://B,gcomm://C,gcomm://
2. Node A: удаление gcomm:// в конце строки
3. Nodes B,C: запуск с gcomm://A

NB: нужно обязательно указывать номер порта для Group Communication запросов, по умолчанию это 4567. То есть, правильная запись: gcomm://A:4567

Можно ли с неблокирующим xtrabackup в качестве SST method писать на ноду-донор?

Во время SST clustercheck на доноре будет выдавать HTTP 503, соответственно для HAProxy или другого LB, который использует эту утилиту для определения статуса, нода-донор будет считаться недоступной, равно как и нода, на которую делается трансфер. Но это поведение можно изменить правкой clustercheck, который по сути обычный bash-скрипт.
Это делается следующей правкой:

NB: заметьте, что делать так можно только в том случае, когда вы уверены что в качестве SST используется xtrabackup, а не какой-то другой метод. В нашем же случае, когда мы используем в качестве донора ноду, лишенную нагрузки, подобная правка вообще не имеет смысла.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *