Тревожно низкая производительность с кластером galera

Моя цель — использовать достаточные ресурсы процессора обоих узлов в моем кластере galera, чтобы мой сквозной стек мог поддерживать больше TPS. Прямо сейчас мой полный стек ограничен одним сервером mariadb с 36vcpu, и он может достигать 10000 TPS.

Я хочу поддерживать почти 20000 TPS, используя 2 узла БД в кластере galera (поскольку 1 может поддерживать около 10000 TPS — это было ограничено CPU). На данный момент меня не волнуют разделенные мозги и другие репликации или пограничные сценарии. Сначала я протестировал его с двумя узлами в галере с балансировщиком нагрузки прокси-сервера ha, но получил очень плохие результаты (только 3500 TPS). Я пытаюсь добиться чего-то, чего не может сделать Галера? Пожалуйста, несколько точек зрения.

Любой другой механизм, с помощью которого я могу кластеризовать свою БД, чтобы приложение преодолело ограничение в 10000 TPS на одном узле?


mysql mariadb database-administration percona galera
person LakshayK    schedule 18.01.2017    source источник
comment
Я не эксперт по кластеризации MySQL, но я думаю, что, поскольку вы стремитесь к скорости, а не к репликации, вам следует обратить внимание на архитектуру кластера Shared-Nothing для MySQL, такую ​​​​как NDB, вместо кластера, ориентированного на репликацию, такого как Galera.   -  person JNevill    schedule 18.01.2017
comment
Вы не можете использовать Galera с двумя узлами в производственной системе. Если один узел дает сбой и повторно синхронизируется, второй узел используется для повторной синхронизации, поэтому ваш кластер не работает! Также важно видеть нагрузку. для высокой нагрузки чтения Galera лучший. Также следует подумать о многоадресной рассылке в сети, поэтому узел должен отправлять только на 1 адрес, а не на каждый узел. Оптимизируйте файл my.cnf. и, наконец, используйте MaxScal вместо HaProxy.   -  person Bernd Buffen    schedule 18.01.2017

Ответы (1)


arrow_upward
2
arrow_downward

Каждая транзакция (в Galera) должна в COMMIT раз связаться со всеми другими узлами, чтобы подтвердить, что транзакция будет работать везде. В конце концов, эти узлы должны выполнить транзакцию. В зависимости от множества факторов это усилие может быть или не быть намного меньше, чем усилие исходного узла.

Все формы репликации включают в себя повторение на ведомом устройстве «записи», которая произошла на ведущем. Хитрость заключается в том, чтобы свести к минимуму усилия ведомого; но это можно сделать лишь частично.

Если автономный сервер максимально обрабатывает 10 тыс. транзакций, маловероятно, что какая-либо настройка репликации сможет выполнять 20 тыс. транзакций на 2 узлах. Возможно получить 20 КБ с 3 или более узлами.

Галера, кажется, достигает максимума в 4-5 узлов. То есть синхронизация становится подавляющей, тем самым ограничивая масштабирование.

Oracle «InnoDB Cluster» выглядит многообещающе, поскольку может выйти за пределы 5 узлов. Теперь он доступен в версиях 5.7 и 8.0.

Кластер NDB зависит от «конечной согласованности», которая сильно отличается от «асинхронной» (регулярной репликации), «полусинхронной» или «синхронной» Galera или InnoDB Cluster. Возможно, NDB сияет, если транзакции никогда не конфликтуют друг с другом или, по крайней мере, не исходят из разных узлов.

Были эксперименты, где было достигнуто более 10К. Попробуйте это .

Пожалуйста, опишите ваши «транзакции»; могут быть и другие методы повышения производительности. Например, один INSERT со 100 строками работает примерно в 10 раз быстрее, чем 100 однострочных INSERTs; большая часть экономии на процессоре.

person Rick James    schedule 18.01.2017