gideondebian@xxxxxxxxxxx (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.