Re: Best replication solution?

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 <jeff@jefftrout.com>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/