Re: Terms and Definitions for Database Replication - Mailing list pgsql-www

From Markus Schiltknecht
Subject Re: Terms and Definitions for Database Replication
Date
Msg-id 46E00683.6070807@bluegap.ch
Whole thread Raw
In response to Re: Terms and Definitions for Database Replication  (Robert Treat <xzilla@users.sourceforge.net>)
Responses Re: Terms and Definitions for Database Replication
List pgsql-www
Hi,

Robert Treat wrote:
> Link added.

Thank you.

> 1st paragraph -> "everything less hurts ACID principles and thus isn't 
> transparent to the application";   ACIDity doesn't control transparancy to 
> application, so I would remove the "thus"

Hm.. a database which isn't ACID compliant isn't "transparent" to an 
application which expects an ACID compliant database. But you are right, 
not all applications require full ACIDity.

> Single Master vs. MM ->  I think you should mention that single master is 
> commonly reffered to as "master-slave".

Good tip, thanks.

> Also you should add an explicit 
> example of what MM is.

Hm.. not sure, my primary goal is giving good definitions. Examples are 
good for understanding, but normally aren't general enough. I'll give it 
a try.

> Eager vs. Lazy -> these terms are pretty nebulous in the literature, and your 
> definitions didnt resonate with me. But I don't disagree with it either :-)

Yeah, they are nebulous. The main reason for this nifty distinction is, 
that the Postgres-R algorithm isn't synchronous in the common sense. But 
it replicates data *before* committing to avoid convergence (and 
conflicts). So it's eager, but asynchronous.

> Also, I think you need to add a section on shared nothing vs. shared 
> everything.

Ah... at a certain point during writing that doc, that came to my mind, 
but then it immediately disappeared. I only remembered that there was 
yet another pair of terms. Thank you very much for reminding me.

> And maybe also explain vertical partitioning vs. horizontal 
> partitioning (aka sharding).

Okay, I'll add that as well, makes sense.

> While the first has pretty much nothing to do 
> with replication,

Well, you could spread the vertically partitioned tables across multiple 
nodes, thus requiring distributed querying. There's almost nothing which 
doesn't touch replication. And most things only add complexity ;-)

Thank you for your review.

Regards

Markus


pgsql-www by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: anoncvs.postgresql.org
Next
From: Robert Treat
Date:
Subject: pgfoundry, gborg, cvsup, developer sites down