Re: [Pgcluster-general] PostgreSQL Documentation of

Markus Schiltknecht wrote:
> 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).

Wow, how is that different than an multi-CPU server? I guess I don't
see the point to it. The only value I see to it would be failover if
one of the servers fails, but it seems the failed server would be
holding locks that would make failover difficult to do without
restarting all the servers.

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

OK. I didn't think pgcluster was shared disk. I thought all the
synchronization was via the network.

> (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)

Yes, I think we have that one covered.

> (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)

Covered.

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

Added as a new entry calld Conflict Resolution.

> 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.

One problem I have is that we we have shared disk failover, but no other
shared case with a PostgreSQL implementation, and people don't want to
mention Oracle RAC, so why do we mention it if we have no
implementations even in the works.

> > 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.

OK, agreed, removed.

> > 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?

I am waiting for email from Mitani-san, the pgcluster author.

>
> > 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.

Oh, I am not aware of pgcluster-II. Did you mean pgpool-II? I think
so. I have mentioned pgpool-II now as part of Clustering For Parallel
Query Execution. Is that OK?

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +