On 8/2/07, Dmitry Koterov <dmitry at koterov.ru> wrote:
>
> On 8/2/07, Andrew Hammond <andrew.george.hammond at gmail.com> wrote:
> >
> >
> >
> > > Lag of 1-10 seconds is really usual. It's an unavoidable evil for
> > > slony, unfortunately.
> >
> >
> > I agree that, given the existing design, a lag is unavoidable. Hence the
> > term asynchronous. Exactly how is this evil? It's _exactly_ what the sy=
stem
> > is designed to be.
> >
>
> No, "the evil" is not always "the bad" nor "very-very bad, ghrrr". The
> evil is "the evil", and nothing more. We have to live with it, no more, no
> less. :-)
>
> And I wanded to say that in a lot of cases (e.g. - for realtime websites!)
> the "asynchronous replication" is quite acceptable, if we read a critical
> data from the origin time to time (when a replica is not ready enough). No
> need to refer to non-existed "synchronous replication" in that case - it's
> useless, and that is what I meant.


There are a number of synchronous replication solutions that exist (Oracle
RAC for example), although none for PostgreSQL. On PostgreSQL, you can
implement the semantics of synchronous replication in application or
middleware using two-phase-commit.

And I would strongly disagree that being aware of the difference between
synchronous and asynchronous is "useless". If you are designing / building a
system that depends on "replication", it is clearly important that you be
aware of what the word means. Which is almost certainly quite different from
what you assume it means.

Instead of saying about a "synchronous replication", it is better to explain
> an algorythm of checking if a replica is ready enough comparing to the
> origin state in the past. I have asked this question many time (in this l=
ist
> and directly), but seems people do not understand why this checking is so
> needed and say common words about "synchronous replication" and
> "impossibility" of such check without any detalizations.


We assume and expect that someone would do the basic reading and research
before asking questions. If that's too much effort, sign up for the
appropriate course at your local university or hire a tutor and have it
spoon fed to you. If, on the other hand, you're willing to do some reading,
a good place to start is

http://www.postgresql.org/docs/current/interactive/high-availability.html

And then hit up wikipedia for more details as necessary. Finally, ask
informed, intelligent questions in this forum.

So the answer was practically empty in these cases. I will be very glad if
> anybody of Slony gurus would agree to spend a hour of his time speaking
> single-minded (!) about this subject,


The brief version is that an asynchronous replica gets it's data only after
it has been committed on the origin. So obviously it will be visible on the
origin before it's visible on any replica. This means there must be a window
of time where the new data is exists, but the replica doesn't know about it.
If the replica doesn't know (and again, by definition, it doesn't know)
about the new data, then how can it know how far it is behind? What you
continue to ask for is something that is, _by_definition_, impossible.
Worse, it is _obviously_ impossible. Do you now understand why there's some
frustration with your continuing to ask for it?

because it is very useful for anybody who uses Slony for heavy-loaded
> websites. Without fast words "impossible" and "synchronous replication",
> because for this task the solution have to exist (I am pretty sure).
>

I look forward to seeing your solution.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20070803/=
b7a2a1c1/attachment.htm