public inbox for [email protected]  

help / color / mirror / Atom feed

From: Markus Schiltknecht <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: Replication Docs
Date: Wed, 22 Nov 2006 19:03:44 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

Hi,

Bruce Momjian wrote:
> OK, it is two separate entries now:
> 
> 	http://momjian.us/main/writings/pgsql/sgml/high-availability.html

Yes, that's fine with me.

> Uh, good point.  The title is now "Statement-Based Replication
> Middleware".  That doesn't say multi-master, but it doesn't say
> master/slave either.  The Sequoia PDF you sent me is very detailed:
> 
>   http://www.continuent.org/uploads/sequoia/Resources/2006-08-15Cecchet_ApacheConAsia2006.pdf
> 
> I think we are back to the issue of classification.  We have traditional
> master/slave as slony, and multi-master as perhaps pgcluster, and lots
> in between.  I am thinking pgpool and sequoia fit in there.  I have
> added Sequoia to the Statement-Based Replication Middleware section.

I'll look into that shortly, but I think Emmanuel can better categorize 
sequoia, I've CCed him. I'd certainly categorize it as Multi Master 
Replication (like pgpool, only that it's a poor implementation).

>> Most probably you're already aware that with PGCluster-II we have such 
>> an implementation in the works.
> 
> I do now.  :-)  I think we are OK with the additional sentence about
> shared disk in the Synchonous Multi-Master Replication section, right?

Yes.

> OK, good point, section updated:
> 
> 	  <term>Asynchronous Multi-Master Replication</term>
> 	  <listitem>
> 	
> 	   <para>
> 	    For servers that are not regularly connected, like laptops or
> 	    remote servers, keeping data consistent among servers is a
> 	    challenge.  Using asynchronous multi-master replication, each
> 	    server works independently, and periodically communicates with
> 	    the other servers to identify conflicting transactions.  The
> 	    conflicts can be resolved by users or conflict resolution rules.
> 	    rules.
> 

Good, that sounds better for me.

There's only a typo at the very end:

"..conflict resolution rules. rules."

> Uh, if the data isn't partitioned, what value is there to hitting
> multiple servers, for single query?  I am confused.

Right, makes only sense for complex queries, i.e. when having multiple 
seq scans and/or joins. The executor would have to be super clever for 
such things to happen. Just forget about my comment.

>> But now, the "little delays" certainly is in the wrong place. Such 
>> delays occur before commit, not before returning results.
> 
> Uh, I don't think the little appears to talk about the results but only
> the propogation.
> 
>> Maybe revert it back to "..no propagation delay". Or completely leave 
>> away the "no propagation delay".
> 
> OK, how is this new text?
> 
>   This guarantees that a failover will not lose any data and that
>   all load-balanced servers will return consistent results no matter
>   which server is queried.

I like that wording better, yes.

Regards

Markus

view thread (4+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Replication Docs
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox