Re: Issues with two-server Synch Rep

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Issues with two-server Synch Rep
Дата
Msg-id 1286827287.24886.23.camel@jdavis-ux.asterdata.local
обсуждение исходный текст
Ответ на Re: Issues with two-server Synch Rep  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Issues with two-server Synch Rep  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, 2010-10-11 at 15:22 -0400, Robert Haas wrote:
> >> This is a completely separate issue from making replication
> >> synchronous.  And, really?  Useless for running read queries?
> >
> > Absolutely.  For a synch standby, you can't tolerate any standby delay
> > at all.  This means that anywhere from 1/4 to 3/4 of queries on the
> > standby would be cancelled on any high-traffic OLTP server.  Hence,
> > "useless".
> 
> What is your source for those numbers?  They could be right, but I
> simply don't know.

I was initially taken aback by the word "useless" as well. However, I
had trouble thinking of a use case that isn't better solved by sync rep
without HS, or async rep. I don't have the numbers either though, so
perhaps someone does have a use case.

> It would be far better if we could decouple master cleanup from
> standby cleanup, so that only the machine that actually has the old
> query gets bloated.  However, no one seems excited about writing that
> code.

That doesn't seem just a matter of code, it seems like a major design
conflict. If the master removes a tuple and then re-uses that space for
another tuple, you can't move those changes to the standby unless you
cancel queries dependent on the first tuple.

> A further grump about our current architecture is that it doesn't seem
> at all clear how to make it work for partial replication.  I have to
> wonder whether we are going down the wrong path completely and need to
> hit the reset button.  But neither this nor the pruning problem are
> things that we can reasonably expect the sync rep patch to solve, if
> we want it to get committed this release cycle.

What we have is physical replication, but you seem to be talking about
logical replication (evidence: Slony solves both the independent cleanup
problem and partial replication).

Both logical and physical replication have a place, and I don't believe
either is the "wrong" path. If we'd like to add logical replication, we
may be better of starting with Slony (or Londiste) and working from
there.

Regards,Jeff Davis



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Issues with two-server Synch Rep
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Issues with two-server Synch Rep