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

 

Percona XtraDB

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

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

 

XtraBackup

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

  1. Делаем дамп 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!

Записываем куда-нибудь позицию и номер бинлога — потом пригодится.

  • Переливаем дамп на нужную машину.
  • Если есть место, распаковываем дамп в два места: одно в датадир, второе — где хранить сырой дамп (без —apply-log).
  • TheSlave$: innobackupex —apply-log /path/to/datadir.
  • TheSlave$: chown -R mysql:mysql /path/to/datadir.
  • Создаем на мастере юзера:
CREATE USER 'lla_slave'@'%' IDENTIFIED BY '123'; GRANT REPLICATION SLAVE ON *.* TO 'lla_slave'@'%';

На слейве (обрати внимание на пункт 7):

CHANGE MASTER TO
MASTER_HOST='10.54.144.81',
MASTER_USER='lla_slave',
MASTER_PASSWORD='123',
MASTER_LOG_FILE='binlog.000001',
MASTER_LOG_POS=64369651
;
  1. Получаем готовый слейв, с которого можно начинать читать данные.

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

 

Percona Toolkit

Percona Toolkit некогда назывался Maatkit, потом ребята из Percona его выкупили вместе с проектом Aspersa, слили их воедино и продолжили разработку. Что такое Percona Toolkit? Это набор опенсорсных инструментов (GPLv2) для удобного администрирования баз данных, основанных на MySQL. Его возможности включают (но не ограничиваются этим):

  • Проверку целостности репликации путем сравнения данных на мастере и слейве.
  • Эффективное архивирование строк.
  • Поиск дублирующихся индексов.
  • Сбор общих данных о серверах MySQL.
  • Анализ запросов из различных источников.
  • Сбор общих данных о системе, которые могут быть полезны при решении связанных с БД проблем.

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

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

 

 

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

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

#!/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-duplicate-key-checker и pt-index-usage для анализа использования индексов и ключей. Первый проверяет вывод SHOW CREATE TABLE по всем таблицам и, если находит индексы, покрывающие одинаковые колонки вместе с другими индексами, выводит их списком. По умолчанию учитываются только индексы одинаковых типов. То есть если одна и та же колонка попадет в индекс типа BTREE и FULLTEXT, то это не будет считаться пересечением. Но можно непосредственно указать для учета подобных случаев. Второй же подключается к мускулю, читает query_log, прогоняет их через EXPLAIN, собирает статистику и в итоге предоставляет подробную информацию о запросах, которые индексы не используют.

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

 

Помимо чисто мускулевых утилит, в Percona Toolkit входит еще несколько инструментов общесистемной направленности. pt-summary, к примеру, собирает общую информацию о системе, на которой был запущен: хостнейм, аптайм, нагрузку, информацию о процессоре, платформе, версии ядра, компиляторе и прочее-прочее. pt-diskstats собирает информацию о дисковой подсистеме из /proc/diskstats. Можно сказать, более понятная и удобная версия iostat’а. А pt-ioprofile уже более детально разбирает, какой процесс какие файлы использует, как часто, как долго, с какой интенсивностью, сколько времени уходит на чтение, сколько на запись и прочее. Помогает найти корни многих нестандартных и не очень явных проблем. По умолчанию он находит процесс мускуля и диагностирует именно его, но можно непосредственно указать PID другого процесса, с которым хотелось бы разобраться.

 

 

Percona Data Recovery

Data Recovery — это набор инструментов для восстановления удаленных или поврежденных данных из таблиц InnoDB/XtraDB. Он дает возможность вытащить данные из файлов баз даже в случаях, когда InnoDB recovery оказывается бессилен. Например, дропнутые таблицы или такое количество повреждений, когда InnoDB вообще перестает признавать в файле базы своего, — во многих подобных случаях Percona Data Recovery эффективно приходит на помощь.

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

  • Останавливаем базу.
  • Вытаскиваем из нее ibd-файлик таблицы, которую попортили.
  • Разбираем файл таблицы на отдельные страницы:
# ./page_parser -5 -f data/vip_data_crashed.ibd
Opening file: data/vip_data_crashed.ibd:
[...]
23.15% done. 2014-08-14 13:10:08 ETA(in 00:00 hours). Processing speed: 101357600 B/sec
  • Парсим полученные данные в поисках данных, помеченных как удаленные:
# ./constraints_parser -5 -D -f pages-4321221407/FIL_PAGE_INDEX/0-23/ > data/vip_data_crashed.recovery
  • Руками выбираем из полученного только те данные, которые мы похерили случайно.
  • Заливаем найденные файлы в таблицу через LOAD DATA INFILE.
mysql> LOAD DATA INFILE '/root/recovery-tool/data/vip_data_crashed.recovery' REPLACE INTO TABLE `vip_data_crashed` FIELDS TERMINATED BY '\t' OPTIONALLY ENCLOSED BY '"' LINES STARTING BY 'datastring\t' (name, from_date, index, date);

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

 

Откуда есть пошла Percona

Петр Зайцев несколько лет назад был тимлидом в отделе высоких нагрузок в компании MySQL Inc., разработчике одноименной базы данных. В 2006 году Петр совместно с Вадимом Ткаченко открыли компанию Percona, основными целями которой были техническая поддержка и консультирование по работе с MySQL, обучение инженеров. Еще с до-Percona времен ведет блог, в котором делится секретами по оптимизации и тонкой настройке MySQL-серверов.

Вадим Ткаченко до основания Percona также работал в High Performance Group в MySQL Inc. около четырех лет. Вместе с Петром и Бароном Шварцем (Baron Schwartz) в 2008 году выпустили книгу «High Performance MySQL» в издательстве O’Reilly.

Со временем Percona начали расти и расширять круг интересов. Завели собственную ежегодную конференцию, посвященную MySQL, — Percona Live MySQL Conference, регулярно проводят в разных точках планеты небольшие технические тренинги под названием Percona University. Дорабатывают оригинальный код от Oracle, исправляют ошибки, выпускают под свободными лицензиями собственные инструменты и разработки, принимают заказы на разработку новых.

 

Заключение

Как видишь, прогресс совсем не стоит на месте. И привычный мускул он не обошел стороной. И даже несмотря на то, что большие покровители Java не очень-то стараются для его развития, это ему никак не мешает. Percona Server уже сейчас можно без особой боязни использовать в продакшене. Например, у нас он крутится уже в нескольких проектах и в целом держит до 7–10k queries-per-second на проект и не жужжит. Чего и тебе желаю :).

Оставить мнение

Check Also

ОС максимальной секретности. Выбираем дистрибутив для обхода блокировок и защиты от слежки

Возможно, ты уже пользовался дистрибутивом Tails или даже запускаешь его ежедневно. Но это…