If the delay between sites is unacceptable, then you most certainly
do not want a synchronous replication system, because then everybody
goes slow for all updates. So you'll need to figure out how you plan
to deal with conflicts when each site updates the same row and the
conflict is discovered after commit but during the asynchronous merging.
I don't know what your usage model is, but 256k isn't all that bad
for a lot of stuff, if the latency is low. Then again, it *is* pretty
bad for a lot of other stuff. :)
On Nov 10, 2006, at 3:42 AM, Gideon wrote:
> Thanks for the quick reply.
>
> We basicaly need to run a database servers in 2 different
> towns. Now there will be update's and selects and both need
> to be in sync with each other. Aswell as if / when database in
> town 1 goes down ... we need to be able to switch to the database
> in town 2 for emergency purposes. We cannot use just one master
> as the connectivity between the two towns isn't fast enough for
> the amount of users that will be viewing data through the connection.
>
> (The fastest affordable connection here for this purpose is round
> about
> 256k.)
>
> Regards
> Gideon
>
> Richard Huxton wrote:
>> Gideon wrote:
>>> Hi
>>>
>>> I have done some research and it seems there are no active mirroring
>>> solutions for postgresql 8 and above. I did see Slony but I need
>>> Master to Master functionality and not only Master to Slave/'s.
>>
>> That's not "mirroring", it's known as "multi-master replication".
>> Mirroring is generally considered single-master => single-slave.
>> Or duplicate queries perhaps.
>>
>> >Is
>> > anyone aware of any mirroring solutions for postgres ?
>>
>> I don't know of any plug-and-play system either. Some support for
>> two-phase commit was added recently and I believe Slony might be
>> supporting multi-master in its next version.
>>
>> Having said that, I'm not aware of any generic solution (for any
>> RDBMS) that can handle all the permutations of peoples
>> requirements. It might be that you can assemble something that
>> meets your needs - can you share any details about how/why you
>> intend to use this?
>>
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that
> your
> message can get through to the mailing list cleanly
