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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-admin by date

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