Re: Terms and Definitions for Database Replication

From: Markus Schiltknecht <markus(at)bluegap(dot)ch>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: pgsql-www(at)postgresql(dot)org
Subject: Re: Terms and Definitions for Database Replication
Date: 2007-09-06 13:54:11
Message-ID: 46E00683.6070807@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-www by date

  From Date Subject
Next Message Robert Treat 2007-09-06 14:29:19 Re: Terms and Definitions for Database Replication
Previous Message Magnus Hagander 2007-09-06 13:22:05 Re: anoncvs.postgresql.org