Этот пост написан Питером Боросом из блога MySQL Performance.
Сегодняшнее сообщение в блоге о погружении в воды буферного пула MySQL является перекрестной публикацией из инженерного блога Groupon и является частью 1 из 2. Спасибо Кайлу Оппенгейму из Groupon за участие в этом проекте и публикации. Мы будем публиковать часть 2 в четверг. Я буду на Percona Live MySQL Conference and Expo на следующей неделе в Санта-Кларе, Калифорния, так что поищите меня там — я бы хотел подключиться и поговорить побольше о буферных пулах MySQL или обо всем, что у вас на уме!
Там являются многочисленные решения для MySQL высокой доступности. Многие полагаются на асинхронную репликацию MySQL для поддержки сервера «горячего» резервирования, который включается в работу, если у активного главного сервера есть проблема. В Groupon наша стандартная конфигурация базы данных MySQL следует этому активному / пассивному шаблону. Существует виртуальный IP-адрес, который указывает на активный сервер пары. На пассивном сервере mysqld запущен и реплицируется с активного мастера. Теоретически переключение при сбое — это простой вопрос перемещения виртуального IP. На практике это немного сложнее. Для управления этим процессом мы используем инструмент, разработанный совместно с Percona.
«Теплый резервный сервер»? Вы это поймали? Что это значит? В большинстве этих решений высокой доступности это означает, что mysqld работает на резервном сервере и репликация не отстает. К сожалению, этого часто недостаточно для аварийного переключения при пиковом трафике. Резервный сервер не обрабатывает трафик запросов, за исключением репликации. Пул буферов и адаптивный хэш-индекс на резервном сервере не будут иметь недавно посещенных страниц. Когда он начинает обрабатывать запросы после отработки отказа, более низкая частота обращений в кэш может привести к сбоям . В частности, в Groupon наши серверы были бы сильно связаны с вводом-выводом после отработки отказа, поскольку страницы пула буферов были загружены с диска.
Воспроизведение запросов
Работая с Groupon , мы разработали решение, позволяющее поддерживать кеши резервного сервера. (См. Мои слайды Fosdem 2013 для информации об отказавшихся проектах и тестах.)
Во-первых, мы устанавливаем long_query_time в 0 для регистрации каждого запроса. (См. Вторую часть для обработки большого объема медленных журналов.) Медленные журналы обслуживаются через HTTP mysql_slowlogd . Этот демон похож на запуск tail -f slow.log, за исключением того, что он знает, как следить за потоком журналов по событиям ротации журналов. На резервном сервере журналы воспроизводятся с помощью Percona Playback путем потоковой передачи медленного журнала с активного сервера.
wget -q -O - http://master_server:3307/slow | percona-playback --mysql-host 127.0.0.1 --mysql-username playback --mysql-password PaSSwOrd --mysql-schema schema_name --query-log-stdin --dispatcher-plugin thread-pool --thread-pool-threads-count 100 --session-init-query \"set innodb_fake_changes=1\" > /var/log/playback.log 2>&1 &
Наша отличная команда разработчиков добавила несколько функций в Percona Playback, чтобы он лучше работал в этом случае. Вам понадобится версия 0.6 или выше, чтобы получить эти функции. Имейте в виду, что при воспроизведении вывод действительно подробный, скорее всего, вы хотите, чтобы он перенаправлялся в / dev / null, и у вас есть только файл журнала для целей отладки.
- Потоковая передача журналов из stdin Percona Playback теперь поддерживает параметр командной строки –query-log-stdin для приема бесконечного потока запросов на воспроизведение.
- Воспроизведение только для чтения. Используя опцию командной строки –session-init-query, мы устанавливаем опцию innodb_fake_changes, чтобы предотвратить INSERT, UPDATE и DELETE от повреждения данных на резервном сервере. Вам понадобится Percona Server , чтобы использовать innodb_fake_changes.
- Пул потоков Percona Playback добавил параметр пула соединений через –dispatcher-plugin-thread-pool, который позволит повторно использовать соединение. Это необходимо при выполнении большого потока запросов.
Ориентиры
Мы сравнивали с медленными журналами запросов, полученными из наших производственных систем. Мы восстановили резервную копию рабочей базы данных в нашей тестовой базе данных, чтобы наша тестовая база данных была согласованной до применения трафика захваченных запросов. Это важный шаг, потому что операторы обновления, которые не соответствуют ни одной строке, или операторы вставки, которые содержат повторяющиеся ошибки ключа, могут выполняться быстрее, чем фактическая запись в базу данных.
Медленные журналы были разбиты на куски, каждый из которых содержал примерно 1 млн запросов. Мы согрели холодную базу данных первым блоком и повторили второй блок после прогрева.
Ось Y является логарифмической, поэтому разница между использованием ввода-вывода составляет 2 порядка. Все графики выглядели так (мы сделали 39 измерений), на следующем графике показана рабочая нагрузка блока 4, подогретая блоком 3.
Результат одинаков для каждого отдельного графа, каждый блок подогревает буферный пул для следующего.
В качестве дополнительного эксперимента мы снова попытались воспроизвести тот же фрагмент. Мы ожидали, что все будет кешироваться, если мы согреем кеш точно такими же данными. Все графики из таких экспериментов по самосогреванию выглядят так. Зеленая часть графика совпадает с синей.
Возвращайтесь в четверг для части 2!