Re: Best replication solution?

От: Jeff
Тема: Re: Best replication solution?
Дата: ,
Msg-id: 77A7A940-78F9-4729-A28E-44270CB7C330@torgo.978.org
(см: обсуждение, исходный текст)
Ответ на: Re: Best replication solution?  (Dimitri Fontaine)
Список: pgsql-performance

Скрыть дерево обсуждения

Best replication solution?  (Lists, )
 Re: Best replication solution?  (Lists, )
  Re: Best replication solution?  ("Greg Sabino Mullane", )
  Re: Best replication solution?  (Heikki Linnakangas, )
   Re: Best replication solution?  (Lists, )
    Re: Best replication solution?  (Ivan Voras, )
   Re: Best replication solution?  (Marinos Yannikos, )
 Re: Best replication solution?  (Andrew Sullivan, )
  Re: Best replication solution?  (Lists, )
   Re: Best replication solution?  (Andrew Sullivan, )
  Re: Best replication solution?  (Dimitri Fontaine, )
  Re: Best replication solution?  (Mark Kirkwood, )
   Re: Best replication solution?  (Andrew Sullivan, )
    Re: Best replication solution?  (Mark Kirkwood, )
    Re: Best replication solution?  (Jeff, )
     Re: Best replication solution?  (Dimitri Fontaine, )
      Re: Best replication solution?  (Jeff, )

On Apr 8, 2009, at 4:46 PM, Dimitri Fontaine wrote:

>
> $ londiste.py setup.ini provider add schema.table
> $ londiste.py setup.ini subscriber add schema.table
>

That is nice.  One could probably do that for slony too.

I may try some tests out with londiste.. I'm always open to new
(ideally, better) things.
>
> This could happen in Londiste too, just set pgq_lazy_fetch to a
> reasonable value and Londiste will use a cursor to fetch the events,
> lowering the load. Events are just tuples in an INSERT only table,
> which when not used anymore is TRUNCATEd away. PGQ will use 3 tables
> where to store events and will rotate its choice of where to insert
> new envents, allowing to use TRUNCATE rather than DELETE. And
> PostgreSQL is quite efficient to manage this :)
>  http://wiki.postgresql.org/wiki/Londiste_Tutorial#Londiste_is_eating_all_my_CPU_and_lag_is_raising
>

Well, Slony always uses a cursor to fetch, the problem is it may have
to slog through millions of rows to find the new data - I've analyzed
the queries and there isn't much it can do -  lots of calls to the
xxid_ functions to determine whats to be used, whats not to be used.
When all slaves have a sync event ack'd it is free to be removed by
the cleanup routine which is run every few minutes.

>
> Oh and some people asked what Londiste with failover and DDL would
> look like. Here's what the API being cooked looks like at the moment:
> $ londiste setup.ini execute myddl.script.sql
>
> $ londiste conf/londiste_db3.ini change-provider --provider=rnode1
> $ londiste conf/londiste_db1.ini switchover --target=rnode2
>

ok, so londiste can't do failover yet, or is it just somewhat
convoluted at this point?

--
Jeff Trout <>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/





В списке pgsql-performance по дате сообщения:

От: Mark Wong
Дата:
Сообщение: Re: linux deadline i/o elevator tuning
От: Scott Carey
Дата:
Сообщение: Re: linux deadline i/o elevator tuning