"Clustering"

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