Re: Database Mirroring Solution

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Database Mirroring Solution
Date: 2006-11-10 13:41:51
Message-ID: 87hcx7h10g.fsf@wolfe.cbbrowne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

gideondebian(at)isogo(dot)co(dot)za (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.)

There was a "Slony-II" project that intended to provide multimaster
support; there were a number of performance and functionality
pathologies that led to most of the efforts being dropped. It's worth
noting that nodes would have been required to be on a very fast local
LAN; you would NOT be running multimaster across a slow link.

Multimaster replication is not likely to work over a slow link, unless
you are willing to take on considerable risks of:
a) Loss of data integrity and
b) Potential for introduction of conflicting updates.

Multimaster replication tends to lead to a pretty big "performance
hit."

If on a fast network, the "moral slowdown" might be on the order of
the difference between CPU speed and network speed, namely that peak
performance falls by a factor of, say, 80 (that being the ratio
between 1 GHz, a common CPU speed, and 100 mbits/s).

If you can only get 256Kbits/s, then you could expect a further
400-fold slowdown. (Which amounts to being ~30,000 times as slow as a
single node...)

That's "back of the napkin" estimation, but it's the sort of slowdown
that attempts to apply general purpose multimaster replication leads
to...
--
output = ("cbbrowne" "@" "gmail.com")
http://cbbrowne.com/info/lsf.html
Howe's Law:
Everyone has a scheme that will not work.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Shane Ambler 2006-11-10 13:56:03 Re: Database Mirroring Solution
Previous Message Marcus Engene 2006-11-10 13:35:22 tsearch2() with data from other table