MySQL 5.5 GA vs Percona Server 5.5: что выбрать для продакшн-нагрузки

В декабре Oracle выкатил MySQL 5.5 GA. Главное изменение, которое волновало практиков: InnoDB стал движком по умолчанию. Для тех, кто помнит дискуссии «MyISAM или InnoDB» на каждом новом проекте - это решение, принятое наконец на уровне дистрибутива.

Параллельно Percona выпустила свой Percona Server 5.5 с XtraDB - патченой версией InnoDB с улучшенным I/O-планировщиком, дополнительными переменными тюнинга и лучшей работой с многоядерными CPU. Drop-in замена: бинарно совместима с MySQL 5.5, данные переносятся без конвертации, конфиг остаётся тот же.

У нас как раз был клиент - небольшой веб-проект, база данных которого выросла до неприличия на MyISAM, и при любой активной записи таблицы просто вставали на table lock. Решили совместить полезное с полезным: мигрировать с MyISAM на InnoDB и заодно сравнить vanilla MySQL 5.5 с Percona Server 5.5 на реальной нагрузке.

Что не так с MyISAM в 2011-м

MyISAM привлекателен своей простотой и скоростью на чтение. На read-only нагрузке с хорошей кеш-прогретостью он нередко быстрее InnoDB - за счёт отсутствия overhead на MVCC и управление транзакциями. Но у клиента нагрузка смешанная: пользователи активно пишут сессионные данные, счётчики, логи действий. И вот здесь MyISAM превращается в узкое место: table-level lock означает, что одна активная запись блокирует всех читателей. Растущий трафик сделал это из теоретической проблемы в практическую.

Переход на InnoDB решает это через row-level locking - конкурирующие запросы больше не блокируют друг друга на уровне таблицы, если не трогают одни и те же строки.

Как мигрировали

Схема несложная, но требует аккуратности:

• Сначала - бекап. mysqldump с явным --single-transaction для согласованного снапшота (на MyISAM это не даёт транзакционной гарантии, но хотя бы фиксирует момент).
• ALTER TABLE ... ENGINE=InnoDB для каждой таблицы в часть нагрузки - последовательно, начиная с наименее критичных.
• Ревизия индексов. У MyISAM часть индексов была создана «на всякий случай» - в InnoDB они стоят дороже на запись, убрали лишнее.
• Тюнинг innodb_buffer_pool_size - это главная ручка: поставили 70% от RAM сервера, что стандартно для выделенного MySQL.

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

MySQL 5.5 GA vs Percona Server 5.5

После стабилизации на InnoDB подняли второй сервер с Percona Server 5.5 и прогнали sysbench на OLTP-паттерне - смешанная нагрузка, read/write в соотношении примерно 70/30, конкурентность 16 потоков.

Цифры примерные, но разница воспроизводилась стабильно: Percona Server давал примерно на 15% больше транзакций в секунду на той же железке. На операциях с интенсивной записью разрыв был выраженнее, на чтении - поменьше.

Откуда прибавка у Percona:

• XtraDB и I/O-планировщик. Percona переработала внутренний purge и flushing механизмы InnoDB - меньше contention на I/O в пиках.
• innodb_io_capacity и дополнительные переменные. В vanilla MySQL 5.5 часть опций тюнинга просто нет; в Percona они есть и работают.
• Улучшенная работа с несколькими CPU. На нашем четырёхъядерном сервере Percona лучше использовала параллелизм.

Это не означает, что vanilla MySQL 5.5 плох - он значительно лучше 5.1 уже за счёт нормального InnoDB по умолчанию. Но если нагрузка реально OLTP и сервер выделенный - разница заметная.

Что получил клиент

До миграции: при пиковой нагрузке таблицы на MyISAM вставали, запросы копились, SHOW PROCESSLIST показывал сотни ожидающих потоков в состоянии «Waiting for table lock». После - этого состояния нет в мониторинге вообще. Время ответа на страницы с активной записью упало примерно вдвое.

Параллельно прирост от Percona Server дал дополнительный запас по пропускной способности - сейчас сервер загружен примерно на 60% там, где раньше уходил в красную зону.

Что думаем

На новых проектах ставим Percona Server 5.5 по умолчанию там, где MySQL вообще в стеке. Аргументов против немного: бинарная совместимость полная, поддержка сообщества активная, документация нормальная. Дополнительные переменные тюнинга дают гибкость без необходимости патчить ядро.

MyISAM продолжает жить в специфических сценариях - read-only архивные таблицы, полнотекстовый поиск (у InnoDB FULLTEXT тогда ещё не было). Но для основной рабочей нагрузки веб-приложения - InnoDB и только InnoDB.

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