Percona server что это

Сервер Percona для MySQL — Percona Server for MySQL

Percona Server for MySQL — это система управления реляционными базами данных (СУБД) с открытым исходным кодом. Это бесплатная, полностью совместимая замена Oracle MySQL. Программное обеспечение включает в себя ряд масштабируемость, доступность, безопасность и функции резервного копирования доступны только в коммерческой версии MySQL Enterprise. Программное обеспечение включает XtraDB, расширенный дистрибутив InnoDB Storage Engine.

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

См. Также

Портал бесплатного программного обеспечения и программного обеспечения с открытым исходным кодом

Сравнение систем управления реляционными базами данных

Percona Server with XtraDB

Percona Server with XtraDB это модифицированная версия СУБД MySQL. Несмотря на то, что разработкой MySQL занимается корпорация Oracle, команде разработчиков из Percona удается сделать эту систему еще лучше и мощнее. Многие из сотрудников Percona являлись разработчиками MySQL в Sun и MySQL AB, поэтому знают об этой СУБД не понаслышке.

Примечательно, что компания создана русскими разработчиками. Генеральный директор — Петр Зайцев, технический директор — Вадим Ткаченко. Percona Server используется многими крупными веб-компаниями, такими как Etsy, Opera. Percona Server наследует все сильные стороны MySQL и отличается отдельными доработками.

Улучшения по сравнению с MySQL:

усовершенствованная статистика производительности;
частные оптимизации скорости работы и стабильности производительности;
поддержка технологии FlashCache;
улучшенная вертикальная масштабируемость;
оптимизации для использования с SSD;
поддержка NoSQL socket;
возможность сохранения состояния Buffer pool;
возможность тонкой настройки параметров InnoDB.

Мы используем эту СУБД как в разработке, так и на боевых серверах для достижения высоких стандартов производительности и стабильности.

Ускорение сайтов

Экспертное ускорение сайтов

Ускорение сайтов
Цена от 69 900 Р

Обзор Percona и сопутствующих инструментов

Форк MySQL Percona Server, как и утилиты от Percona, существуют довольно давно, однако мы очень часто встречаем среди коллег по цеху и сотрудников наших клиентов боязнь их использовать или желание «разобраться в будущем». При этом, использование классических средств (таких как, например, mysqldump/dumper итд), при применении утилит от Percona, практически теряет смысл. Сегодня мы хотим познакомить вас с утилитами и средствами, которые мы применяем регулярно, и о которых грамотному системному администратору надо знать и уметь ими пользоваться.

PERCONA XTRADB

Откровенно говоря, Percona Server — это не форк. Это сборка обычного MySQL с дополнительными патчами. Основная его изюминка — это включённый по умолчанию движок XtraDB storage engine. В версиях MySQL 5.0 и 5.1 Percona Server (а тогда — плагин Percona XtraDB) был настоящим прорывом, но и сейчас, в версиях 5.5 и 5.6, Percona Server проявляет себя лучше штатного MySQL.

Отличается от MySQL+InnoDB plugin большей производительностью/масштабируемостью, особенно на современных многоядерных серверах. Также улучшена функциональность: появилось больше полезной для оптимизации статистики и пр. В нём сохранена полная совместимость с таблицами InnoDB, то есть можно переключаться между InnoDB и XtraDB без каких-либо последствий (если не использовать некоторые специфичные для XtraDB функции, типа меньшего размера страницы).

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

XTRABACKUP

Самым важным и полезным инструментом из тех, что разрабатывает Percona помимо XtraDB, как нам кажется, является XtraBackup. Он позволяет, ни много ни мало, снимать бэкапы баз данных на движках InnoDB и XtraDB прямо на лету. По сути, XtraBackup просто копирует текущую директорию с данными при включенном сервере, что делает такую копию «неисправной», а затем восстанавливает директорию по сохраненным логам, как это сделал бы MySQL во время crash recovery.

Никаких остановок БД, практически никаких (кроме копии MyISAM) локов, зависающих запросов, чем нам всегда был так мил старый добрый mysqldump. Скорость снятия бэкапа — до нескольких раз быстрее, по сравнению с классическим дампом. Приятный бонус: если у вас на мускуле ведутся бинлоги, то он автоматически досчитывает информацию из них в бэкап с момента начала его создания и предоставляет информацию о том, на какой позиции этот бэкап останавливается. А это открывает вообще шикарные возможности по масштабированию MySQL в боевых условиях. Поднятие слейва ограничивается всего парой команд и при этом не грозит даунтаймом:

Делаем дамп innobackup-ex-ом:

TheMaster$: innobackupex --user=yourDBuser --password=MaGiCdB1 /path/to/backupdir

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

innobackupex: MySQL binlog position: filename 'mysql-bin.003220', position 116756883 130813 23:39:54 innobackupex: completed OK!

Переливаем дамп на нужную машину; если есть место, распаковываем дамп в два места: одно — в датадир, второе — туда, где храним сырой дамп, на случай если поднимем слейв некорректно.

Для того, чтобы подняться из бэкапа, применяем лог транзакций (тот самый лог действий с базой, совершенных за время). Из пущей паранойи мы, если процесс применения логов не сильно долгий, запускаем его на нужной машине перед разворачиванием бэкапов. Скрипт innobackupex пересоздаст файлы логов, и если они окажутся не того размера — MySQL упадет:

TheSlave$: innobackupex --apply-log /path/to/datadir

Сложив файлы в datadir, меняем владельца:

TheSlave$: chown -R mysql:mysql /path/to/datadir

На мастере создаем юзера на слейве. Позицию для запуска репликации берем из файла xtrabackup_binlog_info:

CREATE USER 'user'@'1.2.3.4' IDENTIFIED BY '123'; GRANT REPLICATION SLAVE ON *.* TO 'used'@'%';

подключаем к мастеру в нужной позиции:

CHANGE MASTER TO MASTER_HOST='4.3.2.1', MASTER_USER='user', MASTER_PASSWORD='123', MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=64369651;

Получаем готовый слейв, с которого можно начинать читать данные.
Но, как вы наверняка заметили, есть у xtrabackup’а и свои недостатки. Процесс снятия бэкапа с отдельных таблиц усложнен (хотя и возможен), поэтому, если есть необходимость регулярно снимать дампы с каких-то конкретных таблиц и не хочется грузить сервер, то лучше завести для него отдельную реплику и дампить с неё.

PT-ONLINE-SCHEMA-CHANGE

Да, немного забегая вперёд, хотелось бы особенно выделить эту утилиту из комплекта Percona Toolkit. Почему-то так сложилось, что многие наши клиенты про неё совсем не слышали. А ведь это огромное подспорье в очень многих сложных жизненных ситуациях как админа, так и разработчика. Выполнение ALTER TABLE на продакшен-машинах всегда связано с большими проблемами: таблица блокируется на время выполнения, а если таблица большая — блокируется надолго, и сайт лежит.

Что такое pt-online-schema-change? Это мощный инструмент для манипуляций со структурой таблиц БД без простоев и блокировок на чтение и запись.

Как это работает? Если совсем на пальцах, то сначала создаётся копия изменяемой таблицы. С новой структурой в нее копируются данные из оригинальной таблицы, после чего оригинальная переименовывается во временную и удаляется, а новая переименовывается в оригинальную. Процесс переименования нескольких таблиц в MySQL атомарный, поэтому не приводит к ошибкам (таблица не пропадает). Можно указать флаг на сохранение старой таблицы.

pt-online-schema-change -uuser -ppassword -h 127.0.0.1 --alter "ENGINE=InnoDB" D=database,t=table_name --execute --statistics

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

Со всеми деталями можно ознакомиться на официальном сайте:

PERCONA TOOLKIT

Percona Toolkit некогда назывался Maatkit, потом ребята из Percona их выкупили вместе с проектом Aspersa, слили их воедино и продолжили разработку. Что такое Percona Toolkit? Это набор опенсурсных инструментов (GPLv2) для удобного администрирования баз данных, основанных на MySQL. Его возможности включают, но не ограничиваются: детальный анализ статистической информации MySQL (прежде всего — slow log), проверку целостности репликации и восстановление целостности, сбор общих данных о сервере, общий анализ системы, на которой работает MySQL.
Вся информация по скачиванию находится тут: https://www.percona.com/downloads/percona-toolkit/

А теперь по утилитам:

pt-online-schema-change, о котором говорили выше.

pt-query-digest для анализа медленных запросов. Разбирает запросы по времени выполнения, типам, прогоняет запросы для понимания плана выполнения, помогает бороться с медленными запросами. Анализирует MySQL-запросы из логов общих и медленных запросов, из бинарных логов. Также может анализировать текущие активные запросы из SHOW PROCESSLIST и даже просто из дампов мускульного траффика (. ) tcpdump’ом. Очень мощная и удобная штука.

pt-mysql-summary собирает и выдаёт информацию о запущенных на хосте серверах БД. Узнать можно буквально всё: какой версии сервер, со сколькими базами работает, есть ли реплики, какие поддерживаются движки БД, пользователи, привелегии и многое другое.

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

К сожалению, очень часто администраторы и разработчики не задумываются о том, что работающая репликация не означанает синхронности реплицируемых таблиц: нередко в master-master схемах репликации, где работы ведутся на обоих серверах, в результате аварии одинаковые таблицы в реплике могут различаться. Приходят на помощь pt-table-checksum — для проверки консистентности реплики, и pt-table-sync — для синхронизации заданных таблиц. К примеру, с помощью вот такого небольшого скрипта можно собрать полные данные о разнице между мастером и слейвом, если у вас развалилась репликация:

#!/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin echo "SET SQL_LOG_BIN=0;" >/root/desync.sql; for table in `mysql -B -e 'show tables' superdb`; do pt-table-sync --print --nocheck-triggers --sync-to-master --charset=utf8 h=localhost,D=superdb,P=3306,p='SuPeRpAsS',t=$table 2> /dev/null; echo "SET SQL_LOG_BIN=1;" >> /root/desync.sql

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

pt-slave-delay — очень интересная и полезная для MySQL 5.6 утилита, которая фактически заставляла slave-mysql не выполнять транзакции мастера, которые случились менее чем N минут назад. Таким образом можно создать реплику, которая позволит избежать проблемы человеческого фактора: случайное удаление данных, если оно будет вовремя обнаружено, может быть предотвращено остановкой реплики на таком сервере и переключением/восстановлением с него. К сожалению, по нашему опыту, приходится выбирать между актуальной работающей репликой резерва, на которую можно переключиться в случае аварии, и репликой, которая будет защищена от человеческого фактора задержкой репликации. За короткое время задержки можно не успеть остановить репликацию, а за длинное — пропадут свежие данные с основного сервера в случае аварии. Начиная с версии MySQL 5.6 эта функциональность — штатная:

STOP SLAVE; CHANGE MASTER TO MASTER_DELAY = 1800; START SLAVE;

Данная команда укажет реплике не выполнять транзакции ближе чем 30 минут от текущего времени, поэтому утилита имеет смысл для MySQL младших версий. По возможности, мы рекомендуем апгрейд до 5.6 версии. MySQL идет семимильными шагами, и даже если у вас версия 5.5 — стоит обновиться (а если 5.1 — обязательно).

Percona Server

Percona Server — СУБД на платформе MySQL с открытым кодом. Распространяется бесплатно.

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

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

Percona Server 5.6 распространяется бесплатно, платформа — версия MySQL 5.6 с открытым кодом, которую Oracle выпустила в феврале.

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

2016: Percona Server for MySQL 5.7

24 февраля 2016 года компания Percona объявила о выходе Percona Server для расширенного варианта СУБД MySQL 5.7 [1] .

Вышел также релиз свободного продукта 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 также сохраняет курс на повышение производительности, улучшение масштабируемости и обеспечение высокой доступности.

Основные возможности

Модернизация возможностей мониторинга
- Статистика по таблицам, пользователям и индексам предоставляется с минимальным воздействием на производительность и обеспечивает более полное понимание активности на серверах, а также позволяет определять источники нагрузки.
- Расширенное логирование медленных запросов (slow query log) делает возможным более детальный анализ производительности запросов.
- Распределение времени ответа на запрос дает детальную информацию по запросам на чтение и запись отдельно для каждого вида запросов и в течение заданного промежутка времени.
- Пул потоков (thread pool) обеспечивает масштабирование до более чем 10 000 соединений на сервер.
- Плагин аутентификации PAM (Pluggable Authentication Modules) выполняет аутентификацию пользователей MySQL.
- Плагин аудита предоставляет возможность мониторинга на основе политик и логирования активности соединений и выполнения запросов.
- Блокировки для резервного копирования обеспечивают создание резервных копий без существенного снижения производительности.
Примечания
Похожие публикации: