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

Резюме - для создания распределенной системы используйте блокировочные СУБД, а не версионники. Если же хотите открытый движок с очень высокой производительностью, гляньте на berkeley db и sqlite, хотя разработка на них будет посложнее.

pg_man ThamerlanНу если есть интерес к синхронной мультимастер репликации, то можете посмотреть на Cybercluster А если связи не будет, потом подымать бэкапы, синхронизировать...и все практически вручную. Хотя если все это автоматизировать получится асинхронная репликация:-)

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

Ёш MBGМультимастер в постгресе большая идеологическая проблема, поскольку постгрес версионник. Представьте, что на каждом сервере один и тот же документ существует в нескольких версиях (в незафиксированных транзациях), да еще нужно выполнить синхронизацию между серверами. Даже в теории выполнить синхронизацию можно только тогда, когда ни на одном из серверов нет ни одной модифицирующей транзакции на таблице документов или связанных таблицах.почему идеологическая проблема ? %) документ существует только в зафиксированном виде и синхронизировать нужно именно его, документы в незафиксированных транзациях - не существуют.

ps: хотя я может быть просто не понимаю о чём идёт речь %)

Транзакция, которая будет выполнять синхронизацию, тоже до коммита не существует. Например, в 11:59 начинаем транзакцию сохранения новой версии документа, а в 12:00 начинаем транзакцию синхронизации. В 12:01 на сервер сохраняется новая версия документа, но транзакция синхронизации эту новую версию не видит, поскольку внутри транзакции состояние базы "заморожено" на момент начала транзакции. В 12:02 завершается транзакция синхронизации. Вот вам и принципиальная проблема - непонятно даже, как идеологически решать, то ли надо откатывать транзакцию синхронизации, то ли подтверждать. В любом случае сложно предсказать, какая же версия документа окажется на каждом из серверов после их синхронизации. Даже на момент начала синхронизации не удастся точно определить, какая версия документа находится на сервере, так как могут существовать транзакции, изменяющие этот документ, а предсказать заранее, будут ли эти транзакции зафиксированы, нельзя.

Конечно, можно накладывать блокировки разных уровней на синхронизируемые таблицы, но это нарушит нормальную работу системы, да к тому же не поможет разобраться с уже начатыми транзакциями, которые на время блокировки приостановят выполнение.

Andrey Daeron
Че-то странное Вы пишете, уважаемый. А какая нам фтопку разницо?
Есть изменения - должны быть реплицированы на все базы, есть удаления - аналогично, есть вставки - та же фигня.

Если вы пишете свою систему репликации, разница есть. Если берете готовую, тогда дело совести - разбираться, как работает или "на авось".

Andrey Daeron
У нас работает на Оракле (тоже вроде не блокировщик) асинхронная мультимастер репликация и не жужжит. Нормально работает. Хуже с софтом - там много заморочек, например FK, или триггера, коороые зависят от последовательности выполнений... в общем, проблем очень много, но совершенно в другой области.

И как написанную без учета репликации БД в оракл запустить на мультимастере? Даже не стоит обсуждать. В блокировочнике проще. Раз уж вы упомянули оракл, то в качестве примера назову недавно ими купленную berkeleydb - там подобных заморочек с репликацией нет и быть не может. Насколько мне известно, mysql использует подобную низкоуровневую систему. А в оракле это реализуется намного сложнее, и необходимо переписывать базу (функции, триггеры и т.п.).