Dimitry SibiryakovВася да ГамаПри интенсивной вставке со множества клиентов, некоторые из них
замечают только задержку в 5 секунд, а дальше им на логическое имя подкладывается другой
виртуальный айпишник из пула, при этом реплики видят друг-друга нормально, т.е. это не
настоящий отказ, основная продолжает отрабатывать DML для старых клиентов.
Угу. Плюс DML, приходящий через репликацию с других нод.

А теперь следи за пальцами : пусть предельная нагрузочная способность одной ноды 1000
вставок в секунду. Она обрабатывает эту тысячу от "своих" клиентов. А каждая следующая
активная нода начинает присылать ей ещё по 1000.

Что будет в результате? Правильно, нода просядет и либо перестанет принимать поток
репликации (отчего данные на ней рассинхронизируются с соседями и потеряется fault
tolerance), либо перестанет принимать запросы от клиентов (то есть потеряется load balance).

В итоге, полная нагрузочная способность кластера будет какой? Правильно, 1000 вставок в
секунду.



Подключаем пальцы ног. Она не перестанет принимать поток репликации, максимум - она не будет успевает всё коммитить, кэшируя транзакции в журналы по всей группе, а кластер попытается перейти в асинхронный режим (мы ему не позволяем это сделать, принудительно сбрасывая счетчик ожидания отклика).. Вероятность того что все клиенты будут долбить в одно место очень мала, мы еще уменьшаем эту вероятность, используя сегментацию таблиц. В итоге большая часть транзакций будет всегда проходить. В этом поможет также костыль, который синхронизирует транзакции со вторичной реплики, уверяя первую, что она до этого была вторая, а это хвосты после сбоя.

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

Ну и никто же не запрещает делать для группы, то что делается для самостоятельного сервера. Расширение буферного пула к примеру можно сделать на каждом сервере в группе.