Обсуждение: "Clustering"
The heading "Multi-Master Replication Using Clustering" doesn't make sense to me. Clustering is bunching more than host together to achieve a common goal. Thus multimaster replication may be a way to achieve clustering, but clustering is not a way to achieve multimaster replication. I don't actually see clustering defined in the documentation. Can someone explain the categorization? (FWIW, I think "Clustering For Parallel Query Execution" later in the list is an appropriate use of the term.) -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > The heading "Multi-Master Replication Using Clustering" doesn't make > sense to me. Clustering is bunching more than host together to achieve > a common goal. Thus multimaster replication may be a way to achieve > clustering, but clustering is not a way to achieve multimaster > replication. I don't actually see clustering defined in the > documentation. Can someone explain the categorization? I used the term clustering to mean that the servers work closely together. This is not as true with the other items on the page that are not clustering. > (FWIW, I think "Clustering For Parallel Query Execution" later in the > list is an appropriate use of the term.) Yes, I saw it as a similar issue. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Hi, Bruce Momjian wrote: > Peter Eisentraut wrote: >> The heading "Multi-Master Replication Using Clustering" doesn't make >> sense to me. Clustering is bunching more than host together to achieve >> a common goal. Thus multimaster replication may be a way to achieve >> clustering, but clustering is not a way to achieve multimaster >> replication. I don't actually see clustering defined in the >> documentation. Can someone explain the categorization? AFAICS, clustering seems to have no clear definition within database replication. > I used the term clustering to mean that the servers work closely > together. This is not as true with the other items on the page that are > not clustering. Why not simply call in "Multi Master Replication"? That implies clustering, doesn't it? Perhaps you meant a Shared Nothing Cluster by referring to clustering? Such a definition would make more sense. BTW, I'm slowly beginning to accept that you don't want to mix "Statement-Based Replication Middleware" with "Multi Master Replication". ;-) >> (FWIW, I think "Clustering For Parallel Query Execution" later in the >> list is an appropriate use of the term.) That reminds me of the requirement of having Multi Master Replication in place to do Parallel Query Execution. Sync Multi Master Replication being better, while Async Multi Master Replication obviously leads to inconsistent responses, when queried in parallel. That may be acceptable in certain situations. Again, IMHO, "Parallel Query Execution" says everything. The word 'Clustering' does not help, because it's not defined nor commonly used in any helpful way (probably besides marketing). Regards Markus
Hi, I wrote: > That reminds me of the requirement of having Multi Master Replication in > place to do Parallel Query Execution. Sync Multi Master Replication > being better, while Async Multi Master Replication obviously leads to > inconsistent responses, when queried in parallel. That may be acceptable > in certain situations. Oops, during rereading "Clustering For Parallel Query Execution", I've noticed that you mention Data Partitioning as one possible way to do Parallel Query Execution. Thus Multi Master Replication obviously is not a requirement, but just another way to allow for Parallel Query Execution. Mentioning that as well would probably be good. IMHO, the advice to use multiple, independent databases to do parallel query execution sounds a little meager. Of course it's also parallel query execution, but it's not what most people suspect to find under that section, I would guess. Regards Markus
Markus Schiltknecht wrote: > Hi, > > Bruce Momjian wrote: > > Peter Eisentraut wrote: > >> The heading "Multi-Master Replication Using Clustering" doesn't make > >> sense to me. Clustering is bunching more than host together to achieve > >> a common goal. Thus multimaster replication may be a way to achieve > >> clustering, but clustering is not a way to achieve multimaster > >> replication. I don't actually see clustering defined in the > >> documentation. Can someone explain the categorization? > > AFAICS, clustering seems to have no clear definition within database > replication. OK, new title is "Synchonous Multi-Master Replication", and the next heading is "Asynchronous Multi-Master Replication". > > > I used the term clustering to mean that the servers work closely > > together. This is not as true with the other items on the page that are > > not clustering. > > Why not simply call in "Multi Master Replication"? That implies > clustering, doesn't it? Well, not really because of the async multi-master that is the next item. > > Perhaps you meant a Shared Nothing Cluster by referring to clustering? > Such a definition would make more sense. > > BTW, I'm slowly beginning to accept that you don't want to mix > "Statement-Based Replication Middleware" with "Multi Master > Replication". ;-) OK, are they mixed now? > >> (FWIW, I think "Clustering For Parallel Query Execution" later in the > >> list is an appropriate use of the term.) > > That reminds me of the requirement of having Multi Master Replication in > place to do Parallel Query Execution. Sync Multi Master Replication > being better, while Async Multi Master Replication obviously leads to > inconsistent responses, when queried in parallel. That may be acceptable > in certain situations. OK, I think we have that covered now. > Again, IMHO, "Parallel Query Execution" says everything. The word > 'Clustering' does not help, because it's not defined nor commonly used > in any helpful way (probably besides marketing). OK, new title is Multi-Server Parallel Query Execution. If I have just "Parallel Query Execution", it could be multi-process parallel query execution. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Markus Schiltknecht wrote: > Hi, > > I wrote: > > That reminds me of the requirement of having Multi Master Replication in > > place to do Parallel Query Execution. Sync Multi Master Replication > > being better, while Async Multi Master Replication obviously leads to > > inconsistent responses, when queried in parallel. That may be acceptable > > in certain situations. > > Oops, during rereading "Clustering For Parallel Query Execution", I've > noticed that you mention Data Partitioning as one possible way to do > Parallel Query Execution. Thus Multi Master Replication obviously is not > a requirement, but just another way to allow for Parallel Query > Execution. Mentioning that as well would probably be good. Uh, multi-master replication allows for load balancing, but it doesn't help a single query to run any faster. Think of having only one query running on the cluster. Parallel execution allows a single query to use more than one computer, right? > IMHO, the advice to use multiple, independent databases to do parallel > query execution sounds a little meager. Of course it's also parallel > query execution, but it's not what most people suspect to find under > that section, I would guess. Uh, this confuses me. What is missing? You split tables across multiple servers. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +