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@xxxxxxxxxxxxxx so that
your
message can get through to the mailing list cleanly
