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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
