Переход на Percona XtraDB Cluster. Часть II. Накладные расходы на репликацию

Спустя почти месяц после того, как я впервые зафиксировал ^[1] свой опыт использования PXC, я вынужден констатировать, что переноса первых проектов в кластер пока так и не произошло.

Основных причин этому две:

1. Нагрузочные тесты показали приличное снижении скорости записи в режиме кластера
2. В среднем каждые 2-3 дня я ловлю новый глюк, причины которого не всегда удается осмыслить и приходится заново инициализировать кластер.

Справедливости ради отмечу, что некоторые глюки возникают совсем на другом уровне, например в слое балансировки нагрузки или утилите xtrabackup. Но о глюках в другой раз, а в этой заметке я остановлюсь на проблеме из п. 1 и попробую резюмировать главное из того, что я узнал о накладных расходах в Galera репликации и о способах минимизировать потерю производительности, связанную с ними.

Причины

Overhead возникает при операциях записи, что вполне предсказуемо для синхронной репликации. Функция wsrep-провайдера Galera заключается в создании специального набора данных (WriteSet), в который на этапе коммита преобразуется пользовательская транзакция, его передаче все группе узлов кластера, и последующим применении синхронно на всех узлах.

Поэтому накладные расходы в PXC составляют следующие операции:
— создание writesets — подготовка, сериализация, кэширование, и т.п.;
— групповая коммуникация — отслеживание статуса нод в группе, передача writesets по сети;
— локальная сертификация — поиск конфликтов в наборах данных, стоящих в очереди на применение;
— применение writeset, успешно прошедших сертификацию;
— контроль за изменением состояния данных, присваивание Global Transaction ID каждой транзакции;
— запись кэша writesets на диск, если он не помещается в памяти;
— и наверняка много другое

Насколько этот оверхед испортит вам жизнь, зависит в том числе и от ваших конкретных условий — например, конфигурации оборудования или скорости сети. Но совершенно очевидно, что если рядом с вашим текущим сервером БД поставить еще один в такой же конфигурации, и активировать на них Galera репликацию, то вы получите падение производительности записи.

Цифры в студию!

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

www.mysqlperformanceblog.com/2011/10/13/benchmarking-galera-replication-overhead/ ^[2]
www.codership.com/content/scaling-out-oltp-load-amazon-ec2-revisited ^[3]
openlife.cc/blogs/2011/august/running-sysbench-tests-against-galera-cluster ^[4]

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

Что можно предпринять?

Оборудование

ИМХО: решили построить отказоустойчивый кластер — не поскупитесь на хорошее железо.

• установите на каждый сервер хотя бы 4+ (сколько позволяет платформа) SAS, а лучше SSD дисков в аппаратном RAID10
• обратите особое внимание на сетевой компонент — при интенсивной записи вам может не хватить вашего старого доброго свитча, рассмотрите возможность заменить его на хорошую 10Gbit-ную железяку

Конфигурация сервера БД

Конечно же в этой области все очень индивидуально, зависит от многих факторов, но все же есть несколько очевидных настроек.

• innodb_flush_log_at_trx_commit = 0
  В условиях работы с одиночным MySQL сервером мы часто выставляем этот параметр в 1, чтобы избежать потерь незавершенных транзакций при аварийном завершении работы демона. Но в случае с Galera это не требуется, т.к. упавший сервер после восстановления получит IST с одного из других работающих узлов кластера. Сброс данных на диск после каждой фиксации заметно скажется на производительности записи, поэтому в режиме кластера его лучше отключить. На моих тестах это изменение сказалось очень заметно.
• wsrep_slave_threads = CPU Cores * 4
  Этот параметр устанавливает количество потоков сервера, которые производят применение writesets на тех серверах, которые принимают данные с мастера (узла, на который идет запись). К сожалению, скорость записи не увеличится во столько же раз, насколько вы измените эту величину, но и держать ее близкой к 1 тоже не следует. Слишком маленькое значение приведет к увеличению очереди writesets на применение, и это в конечном итоге скажется на времени выполнения запросов.
• query_cache_size = 0
  Рекомендация отключить Query Cache связана с тем, что Galera не поддерживает работу с кэшем результатов запросов в том виде, в каком это делает стандартый MySQL сервер. И если оставить его включенным, мы получим немного лишней логики — на каждый запрос будет производиться вызов валидации кэша, что точно не ускорят процесс обработки запросов.

Процедурные меры

• Если у вас есть необходимость периодически запускать процедуры обновления данных, где с выключенным autommit выполняется большое число INSERT/UPDATE — стоит оптимизировать эти процедуры, разбив запросы на несколько транзакций большого размера. Возможно, ваш текущий MySQL сервер обрабатывает их за сносное время, но в режиме кластера вы получите замедление, из-за того что все составляющие оверхеда будут выполняться для каждого из запросов.
• также стоить рассмотреть возможность увеличения числа потоков для таких пакетных вставок, если позволяют ресурсы сервера и характер самих данных (можно нарваться на дедлоки)

Вывод

Overhead есть.
Но ведь есть и синхронная репликация и гарантированная целостность данных, а с замедлением записи можно и нужно бороться.

Автор: grobbelaar

Источник ^[5]