Re: Database Mirroring Solution

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.