public inbox for [email protected]
help / color / mirror / Atom feedFrom: Markus Schiltknecht <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: [Pgcluster-general] PostgreSQL Documentation of High Availability
Date: Tue, 21 Nov 2006 09:23:50 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
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
view thread (25+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: [Pgcluster-general] PostgreSQL Documentation of High Availability
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox