From: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | pgsql-docs(at)postgresql(dot)org, emmanuel(dot)cecchet(at)continuent(dot)com |
Subject: | Re: Replication Docs |
Date: | 2006-11-22 18:03:44 |
Message-ID: | 45649100.4040505@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-11-22 18:11:15 | Re: [Sequoia] PostgreSQL Documentation of High Availability |
Previous Message | Bruce Momjian | 2006-11-22 17:36:54 | Re: Replication Docs |