Gallemar,

а она где-нибудь есть? Репликация master-slave предполагает отсутствие конфликтов на уровне данных. Репликация master-master предполагает наличие разных конфликтов, некоторые из которых решаются только вручную. Иначе запись на уровне sql-операторов должна синхронно идти в обе БД. Выигрыш по производительности тут получить нельзя, а значит это дело с успехом заменит синхронная или асинхронная репликация мастер-слейв.
Так что определись терминологически, что ты имеешь в виду. СУБД не может обеспечивать репликацию мастер-мастер на отдельных серверах. Такое решение может быть только программным (триггерным, дублирование потока команд из клиента, и т.д.), о чем я и сказал выше.

Gallemar,

да понятно, что multi-master write-scalable cluster. Но про запись я как раз и говорил
"More than 3× scalability performance speedup with five servers, compared with pure PostgreSQL".
То есть, либо мы берем 5 адски дорогих серверов, и получаем трехкратную адскую производительность,
или мы берем 5 дешевых серверов, и получаем ... производительность как у одного дорогого сервера.

KreatorXXIПолучается аналог бэкап-рестор на другом сервере. Только поумнее. В 4.0 планируется такая?
это не бэкап-рестор. База копируется на реплику, стартует мастер, затем реплика, после чего с мастера данные передаются в реплику. Это асинхронное. С синхронной репликацией сначала стартует реплика.

Тут уже несколько раз говорили, что эта репликация и будет в 4.0. И якобы уже есть - репликация через nbackup -b guid. В этом случае репликация асинхронная, изменения накатываются через регулярный инкремент.

KreatorXXIНеужели на рынке востребована реплика read-only?
вы не читаете, что я пишу про мастер-мастер. Такую репликацию можно сделать хоть сейчас через IBPhoenix Replicator, триггерно.
Но вы понимаете, как ваши данные будут ходить из одного мастера в другой и обратно? Если же вы хотите чтобы мастеры были вообще синхронными - то для чего вы этого хотите? Как у вас будет происходить параллельное оформление заказов в обоих мастерах?
А... Идентификаторы надо разнести? А как этим будет сам сервер заниматься? Типа, в мастер1 генераторы одни, в мастер2 другие?
И что будет при падении одного из мастеров, как будет продолжаться работа? Каков будет процесс восстановления?
Неточная терминология плюс собственные фантазии (неподкрепленные технологически) приводят к неверному обозначению проблемы, или неверным попыткам решения проблемы.

Сколько я слышу про репликацию, так все хотят чтобы "из всех баз везде чтобы волшебно синхронизировалось". При этом, казалось бы, дофига статей про специфику репликации, конфликты обновлений, и прочее. Может, мне просто повезло, что я эту репликацию мастер-мастер в Lotus Notes увидел еще в 90х? :-)

KreatorXXIНеужели на рынке востребована реплика read-only?
и еще про это добавлю. На рынке масштабирование производительности отчетов, например, востребовано давно, только все его делают по разному. Кто-то простым бэкап-рестором, кто-то через нбэкап, кто-то через on external, через сервера отчетов, и т.д.
Но больше востребована надежность после сбоя. А read-only реплика этому соответствует, да еще и позволяет масштабирование. И легко превращается в read-write в случае сбоя мастера.
В результате простой сильно сокращается, что и требовалось.
А чего вы хотите от полной репликации мастер-мастер, я не знаю.
Это как в 2008-2009, вдруг внезапно людям захотелось кластер на Firebird. Когда началась разработка, выяснилось, что решение дорогое, и клиенты не особо горят желанием за кластер платить. Соответственно заглохло, по крайней мере на 8 лет.

Я не говорю что мастер-мастер не нужен. Он нужен, вопрос только зачем, и кому.

Dimitry Sibiryakovи обойти которое можно только шардингом.
А шардинг это не мастер-мастер, а по факту или тэйблспэйс на разных серверах, или партиционирование на разных серверах.
Я может утрирую, но опять же, это вопрос терминологии.

KreatorXXI,

я как раз в начале 2000 видел, как люди сами сделали мульти-мастер репликацию на IB - триггеры плюс их софт. Но они это все делали к своей базе. Т.е. база была разработана с учетом репликации. И таких решений - полно. Но чтобы вот прямо master-master на любой базе взял и заработал - я не верю именно в это.

Когда начинаешь тыкать пальцем всякие серверные решения, на поверку оно так и оказывается - там недоделано, тут ограничения, это не работает, и т.д.
https://en.wikipedia.org/wiki/Multi-master_replication

sql anywhere? не вижу. Но да, у него есть SQL Replication, транслируются логи транзакций. PostgreSQL? про него тут уже упоминали.
MySQL? только сегодня специально на хабре нашел описание, там...

Gallemar https://habrahabr.ru/company/oleg-bunin/blog/312494/
в основном маркетинговая чешуя и адский трэш про 2PC.