2017-01-18 19 views
0

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

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

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

+0

Я не эксперт в области кластеризации MySQL, но я думаю, что, поскольку вы стремитесь к скорости и не репликации, вы должны посмотреть на кластерную архитектуру Shared-Nothing для MySQL, например NDB, вместо кластера, ориентированного на репликацию, такого как Galera. – JNevill

+0

Вы не можете использовать Galera с двумя узлами в производственной системе. Если один Node Crashs и повторная синхронизация второго узла используются для повторной синхронизации, поэтому ваш кластер не работает !! Его также важно увидеть нагрузку. для высокой нагрузки на считывание Galera лучше всего. Также подумайте о Multicast в сети, поэтому узел должен отправлять только 1 адрес, а не каждому узлу. Оптимизируйте my.cnf. и, наконец, использовать MaxScal вместо HaProxy. –

ответ

1

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

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

Если автономный сервер выходит из строя при транзакциях 10K, маловероятно, чтобы установил любую репликацию, чтобы иметь возможность делать 20K через 2 узла. Это может быть можно получить 20K с 3 или более узлов.

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

Oracle «InnoDB Cluster» выглядит многообещающим, возможно, выходя за пределы 5 узлов. Он теперь доступен в 5,7 и 8,0.

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

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

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