Skip site navigation (1) Skip section navigation (2)

Re: Postgresql on a shared storage

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Postgresql on a shared storage
Date: 2004-05-31 02:22:00
Message-ID: m3vfidjpyv.fsf@wolfe.cbbrowne.com (view raw or flat)
Thread:
Lists: pgsql-admin
vasil(at)ludost(dot)net (Vasil Kolev) wrote:
> I'm working on a system that has 2 servers with postgresql, and a FC
> shared storage between them, where the database is stored. After
> some weeks of using google and reading lists, I've come to the
> conclusion, that there is no way (using F(L)OSS tools) to use both
> databases R/W, or even one of them R/O, and one of the machines has
> to do all the work, and the other one to be a hot spare. Am I right,
> or have I missed something?
>
> And is there something tested and usable for my case, even if it's
> commercial, that will run under linux?

The only quasi-FLOSS system that bills itself as being good for this
sort of thing is Backplane <http://www.backplane.com/>; it is _way_ too
early for it to be considered mature for the purpose, and it's
licensed under much the same sort of "if you're doing anything
commercial, you have to pay for commercial licenses" arrangement as
MySQL.

The most relevant Oracle thing is RAC.  It looks like it's _very_
expensive, and it's not evident that it allows multiple instances to
share the FC storage.  <http://www.dba-oracle.com/art_rac.htm>

I'm not sure you'll find it easy to find commercial databases that
allow you to spread write load across multiple servers.

What you're looking for is some form of multimaster replication;
that's problematic on any platform.  
-- 
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/linuxdistributions.html
"Optimization hinders evolution."  -- Alan Perlis

In response to

pgsql-admin by date

Next:From: Bruce MomjianDate: 2004-05-31 02:48:33
Subject: Re: Setting vacuum_mem for vacuumdb utility
Previous:From: postgresDate: 2004-05-30 22:39:31
Subject: Re: constraints and performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group