Message-ID: <4562B796.9070601@bluegap.ch>
Date: Tue, 21 Nov 2006 09:23:50 +0100
From: Markus Schiltknecht <markus@bluegap.ch>
User-Agent: Icedove 1.5.0.8 (X11/20061116)
MIME-Version: 1.0
To: Bruce Momjian <bruce@momjian.us>
CC: a.mitani@sra-europe.com, pgsql-docs@postgresql.org,
	pgcluster-general@pgfoundry.org
Subject: Re: [Pgcluster-general] PostgreSQL Documentation of High Availability
References: <200611202216.kAKMGBx16139@momjian.us>
In-Reply-To: <200611202216.kAKMGBx16139@momjian.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Bruce Momjian wrote:
> I feel the shared-* issue splits us up like master/slave and
> multi-master splits up

No, not quite. To sum up, I'd say the following combinations make sense:

sync, multi-master replication on shared-memory cluster (which is much 
like a super-computer. With shared memory distributing locks does not 
cost much - beside marketing, there is probably not much sense in 
calling this a cluster at all).

sync, multi-master replication on shared-disk cluster (where locks and 
memory-caches have to be synchronized. OracleRAC and PgCluster-II fit in 
here.)

(Probably running an async replication on a shared-disk cluster would 
make sense with MVCC and in some corner cases, but I don't see much 
benefits in that.)

sync, multi-master replication on shared-nothing cluster (where locks, 
caches and data needs to be synchronized over an interconnect. 
Postgres-R, PgCluster, PgPool)

(sync, single-master replication does not make much sense, because if 
you go sync at all, you could as well use the nodes which run in sync).

async, multi-master replication on shared-nothing cluster (i.e. Slony-I)

async, single-master replication on shared-nothing cluster (mainly for 
failover purpose, you mention solutions for that)


For me these categorizations are important and help a good deal to 
ensure what I'm talking about with somebody. The documentation is much 
more focused on individual solutions, sometimes avoiding to categorize 
them. I would love to get others opinions, but as not many others speak 
up, I just accept it that way.

> Yea, gets confusing.

Well, Oracle also does a good deal in making it confusing, IMO.

> Good point. I mentioned Oracle RAC only because it seems to be an
> industry standard, so by mentioning it, people know exactly what we are
> talking about.  

That's a point, even if I don't really know how much of an industry 
standard it is. But given how badly Oracle does in explaining basics of 
replication and clustering, I think it's not very beneficial.

> Is there a better way?  And people do ask for Oracle
> RAC, so in a way we are telling them we don't have something similar. 
> As sad as that is, it is true currently.

How far is PGCluster-II? Does it make sense to mention it? Can 
PGCluster-II be used with network filesystems like NFS, OCFS2 or the like?

> pgcluster is must closer to Oracle RAC, 

Why do you think so? Oracle RAC is mainly based on a shared disk 
cluster, where PGCluster bases on a shared nothing architecture. 
PGCluster-II seems closer to Oracle RAC, for me.

> but I haven't mentioned it
> because I am unsure where it is in terms of usability and stability.
> Comments?

Did you work on it since Toronto, Mitani-San?

Regards

Markus