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

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

https://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html

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 Toolkit входит ещё довольно много инструментов, как-то связанных с MySQL общесистемной направленности. Мы остановились на тех, что используем часто сами, и о которых обязательно стоит помнить. Однако есть еще множество утилит, на которые стоит обратить внимание (особо советуем - pt-stalk) — более подробную информацию можно узнать на официальной странице: https://www.percona.com/doc/percona-toolkit/