Re: [Pgcluster-general] PostgreSQL Documentation of High Availability
От | Markus Schiltknecht |
---|---|
Тема | Re: [Pgcluster-general] PostgreSQL Documentation of High Availability |
Дата | |
Msg-id | 4562B796.9070601@bluegap.ch обсуждение исходный текст |
Ответ на | Re: [Pgcluster-general] PostgreSQL Documentation of High (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [Pgcluster-general] PostgreSQL Documentation of
|
Список | pgsql-docs |
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
В списке pgsql-docs по дате отправления: