ОлегНЕсть три ДЦ
есть MySQL
в каждую базу пишется данные из локального ДЦ, и локальный ДЦ с ним работает. Но данные в нём должны быть и из других двух.
всего данных около 300ГБ
если падает канал, то локальная БД должна быть доступна, при возобновлении канала данные реплицироваться.

т.е. синхронная репликация нам не подходит. galera не подходит, mmm не подходит

чем можно такое реализовать?

у postressql есть какие-либо решения для такого?Продолжаете использовать MySQL и ставить GG от Oracle. Технология опробованная и есть примеры использования именно в таком варианте как у вас. Базу данных Oracle DB EE покупать для этого не надо.

pkarklinDimitry SibiryakovИ она работает в мультимастер режиме?..


Peer-to-Peer Transactional Replication подойдет? http://technet.microsoft.com/ru-ru/library/ms151196.aspx Фигня какая-то :)
http://technet.microsoft.com/ru-ru/library/ms151196.aspx Хотя одноранговая репликация позволяет масштабировать операции чтения, производительность операций записи для топологии такая же, как для одного узла.

Dimitry SibiryakovAlexander RyndinФигня какая-то :)
Это не фигня, это объективная реальность. Просто обычно о ней не упоминают.
На каждый из узлов льются изменения со всех остальных. Если общий поток изменений превысит
входную пропускную способность узла - он захлебнётся.
:) Это не всегда так. В GoldenGate есть параметр BATCHSQL, который:
1) делает более крупные транзакции (падает нагрузка на Log Writer)
2) группирует одиночные операции в операции с массивами

Dimitry SibiryakovAlexander RyndinВ GoldenGate есть параметр BATCHSQL, который:
....повышает плотность потока реплицируемых данных, но не более того.

Если одиночная нода с оптимально написанного приложения способна всосать Х гигабайт в
секунду, то кластер из любого числа таких нод в штатном режиме будет способен всосать всё
те же Х гигабайт в секунду. Дальше он либо ограничит входной поток тормозами, либо из
штатного режима выйдет в надежде, что когда-нибудь в него вернётся после того как входной
поток упадёт. Нет серебряной пули.
Серебряной пули не существует, но выполнение пакетных DML вместо одиночных DML повышает пропускную способность сервера для большинства OLTP-приложений. Это факт. Иначе какой смысл в пакетных операциях? :)
Естественно, масштабировать записей репликацией не получится бесконечно.

pkarklinAlexander Ryndin,

Вы можете привести примеры, баллансирующите операции записи?Да. Знаю о случае 16-way репликации в одном большом нероссийском телекоме.

pkarklinAlexander Ryndinпакетных DML вместо одиночных DML повышает пропускную способность сервера

Терминалогию озвучьте в части "пакетных DML".Вот для Java http://docs.oracle.com/cd/B28359_01/java.111/b31224/oraperf.htm

pkarklinAlexander RyndinДа. Знаю о случае 16-way репликации в одном большом нероссийском телекоме.

Пенсионер на приеме у врача жалуется на снижение потенции.
Врач:- А сколько вам лет?
Пациент:- 72. Ну и что. А вот у меня приятель, ему 74, так вот он говорит ...
Врач:- И вы. И вы говорите.Хаха.Смешно.
Вот еще пример с 4-way репликацией. . Кстати, для MSSQL. С целью отказоустойчивости и масштабируемости.

pkarklinAlexander Ryndin,

Причем здесь Java, если мы говорим о репликации силами СУБД?!

Задача простая. На одной из нод выполнено 10 000 инструкций UPDATE. Упакетируйте их для трансляции на остальные 15 нод.Ссылку на Java я приведел исключительно для целей "Терминалогию озвучьте в части "пакетных DML".
И вы все-таки почитайте ссылку про Java, а то получается "не читал, но осуждаю".

Ну и да, что касается GoldenGate, то читайте вот здесь на странице 129 о параметре BATCHSQL.