репликация

http://en.wikipedia.org/wiki/Multi-master_replication#Postgres

google://asynchronous%20multi-master%20replication%20postgres

как ты себе представляешь асинхронный мультимастер?
В общем случае это невозможно, лучше ещё раз подумать над архитектурой приложения.
А в частных случаях ты всё равно никуда не уйдешь от ручного разрешения конфликтов.

1. сделать это на постгресе я смогу, наверное суть вопроса объясненна плохо.

2. гугл выдал 1 030 результатов из которых ни одной толковой доки а больше ссылки на что то невнятное

3. а в вики вообще одна строка :) про постгрес намеки на пгпул и пгкластер (понятное дело $subj будет делаться на pgpool-ii).

4. Переформулировка вопроса: что нужно предусмотреть архитектору-БД и программистам-БД чтобы асинхр мульти мастер репликация не была антипатерном :)) и вообще головной болью учитывая минусы данного подхода.

> В общем случае это невозможно, лучше ещё раз подумать над архитектурой приложения.

дада вот собсно и хочу узнать что сделать чтобы и долго думать (даже долго делать) и сделать мультимастер , но такой чтобы все было здорово? или я туплю и это фантастика?

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

угум ... так то он так, да вот ... нашел книгу таненбаума "Распределенные системы" там как раз о моделях непротиворечивости данных в контексте репликации ... вроде причинная модель непротиворечивости как раз то что нужно для моего случая ... может че и выйдет фиг его знает ... но это походу будет головная боль программистам :)

угу, программистам в этом случае придется попотеть точно.

А откуда возникли требования к именно асинхронному мульти-мастеру?

Ноды будут слишком далеко друг от друга расположены?

ага, именно! географически раскиданны по разным городам

Фантастиш просто. Про синхронную репликацию забудь.

А так: http://pgfoundry.org/projects/pgcluster