Хотелось бы иметь представление, кто работал и работает с GT.M?
Если конкретно, то сейчас у меня ступор связан с репликацией... по существу думаю об использовании Business Continuity (BC) репликации. Но не могу понять можно ли сделать например так: два (и более) равноправных инстанса, наше веб приложение передает запросы равномерно между двумя (и более) инстансами...
Попробую нарисовать здесь как работает сейчас на примере одного инстанса:

Backend Instance:
GT.M (6.0-001) с модулями рутин (условно Backend API)
C++ Backend демон, который создает N GT.M Workers в отдельных процессах,
GT.M Worker также написан на C++ и использует GT.M Call-Ins, получает запросы и отправляет ответы посредством Shared Memory.

Frontend Instance:
PHP приложение, написанное согласно паттерну MVC, в моделях вызываются запросы посредством разработанного PHP расширения
PHP расширение, в котором реализована поддержка Backend API
C++ Gateway демон, который передает запросы и получает ответы от C++ Backend демона по защищенному TCP соединению, запросы же он получает от PHP расширения и ему же отдает ответ.

GT.M - [GT.M Workers - Backend] -------- Gateway - [PHP Extension - PHP App]

Для масштабирования Backend'а на примере двух инстансов мне надо две такие схемы Frontend -- Backend, и на стороне Frontend реализовать балансировщик веб-запросов между двумя схемами (но это не моя задааи). Моя задача - как сделать возможность добавления-изменения-удаления глобалов в GT.M для двух этих инстансов, при этом чтобы данные синхронизировались.
В Business Contiunity репликации есть главный инстанс и вторичный инстанс, и как я понял (или плохо понял?) бизнес логика (Backend API) работает только с главным, а вторичному только передает изменения в главном.

Тоесть бизнес логику и передачу изменений ко вторичному нельзя применить?

PS: Почему так запутано решение это другой вопрос. Мне ответы интересны по репликации данных.

K.S. Bhaskar ответил вот так:

Owing to requirements of transaction integrity for the applications that run on GT.M and the eventual consistency that the CAP theorem imposes, GT.M does not currently support multiple Master/Master operation.

You can certainly implement replication at the application level. For example, create triggers that log updates to a global from where application processes stream updates to other instances.

Теперь сижу и думаю, что зря выбрал GT.M. Но прийдется как то выходить из ситуации. И изучаю подробнее основные SQL/NoSQL базы данных.

Даже не знаю, в Cache' лучще обстоят дела с репликацией?

DAiMor,

Вы правильно поняли то, что мне нужно :)
Спасибо за ответ. Буду думать. Вообще то разработанное решение может и без распараллеливания справится. По сути, увы, самая тормозящая часть это фронтенд. Да и в целом можно было бы проще реализовать все (если бы еще и не требование "как можно лучше спрятать базу данных от взломщиков"). На стороне бекенда скорость порядка 10000 запросов/секунду (нашего API), что я еще могу ускорить еще в 2-3 раза. Но фронтенд запрашивает запросы со скоростью порядка 500 запросов в секунду. Поэтому мы пока думаем распараллелить фронтенд балансировщиком запросов к веб-серверу. А бекенд соответственно сможет легко обслуживать 20 (10000/500) фронтендов. Теоретически :) поскольку я таким еще не занимался. Да и у нас нет таких специалистов.

На будущее думаю уже лучше выбирать БД, от Cache' отказался не я, а начальство :) посколько платно.