Реально работающей асинхронной мульти-мастер репликации в общем виде
нет ни в одной базе, даже коммерческой. Проблемы идеологические, а
именно -- разрешение конфликтов.
Если у вас в одном мастере в таблице users пользователь aaa поменял
свой телефон в колонке phone, а на другом мастере у него же поменяли
колонку address, то replication engine в момент синхронизации
обнаружит конфликт в данной строке. Что ему с ним делать?
Автоматически система сможет принять решение только в том случае, если
администратором была задана policy, разрешающая данный конфликт. А так
как задать абсолютно все policy не представляется возможным, неизбежно
будут возникать ситуации (подчеркиваю, речь идет об _общем_ случае
асинхронной мульти-мастер репликации), когда система будет требовать
мануального разрешения конфликтов.
Так что спрашивайте конкретнее, описывая задачу более подробно. В
настоящее время для решения сложных задач репликации я бы
порекомендовал писать решение самостоятельно на фреймворке обобщенной
очереди PgQ компании Skype. Но его тоже нужно изучать и тестировать,
опыт ее реального использования пока есть только в Skype.
А более общая мысль еще проще: нужно стараться уходить от асинхронного
мульти-мастера, он в некотором роде является архитектурным
антипаттерном, это нужно понимать.
On 4/25/07, Alex Gorbachenko <agent_007@immo.ru> wrote:
> On Tue, 24 Apr 2007 21:22:32 +0600
> alexey wrote:
>
> >http://postgresmen.ru/files/IZ_rit2007.pdf - если верить этому то и
> >PostgreSQL это тоже умеет :)
>
> асинхронный мастер-мастер ? не умеет. да и синхронный тоже. pgcluster
> на реальных задачах не живёт вообще никак. база размером в десяток
> гигабайт и весьма посредственным количеством обращений (5-10 qps)
> вгоняет pgcluster в ступор.
>
> и асинхронный мастер-слейв тоже. если "верить этому", то будет уметь.
>
> --
> np: Bruce Dickinson - Road To Hell
>
>