Re: Replication Docs
От | Markus Schiltknecht |
---|---|
Тема | Re: Replication Docs |
Дата | |
Msg-id | 45649100.4040505@bluegap.ch обсуждение исходный текст |
Ответ на | Re: Replication Docs (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Replication Docs
(Bruce Momjian <bruce@momjian.us>)
|
Список | 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
В списке pgsql-docs по дате отправления:
Следующее
От: Bruce MomjianДата:
Сообщение: Re: [Sequoia] PostgreSQL Documentation of High Availability