On Friday 22 June 2007 03:58:09 pm Andrew Hammond wrote:

> Why do you have an "idle timer" running during a subscribe? Killing
> slons during subscribe is an outright bad idea.

Who said anything about killing slons?  The remote system is a a colo 
where they have a firewall which periodically disconnects things it 
perceives as idle.  There isn't anything we can do about this.  This is 
all part of our migration plan - mirror to the new remote data store, 
do some tests and checks, then switch the master and we're done.

> To smooth your initial subscribe, have you considered breaking it
> into a number of small sets (say with a single table and 
> related sequences in each set) and subscribing them piece by piece?

I was considering that.  I may have to go that direction anyway, but I 
was kinda hoping for another answer. Heh.  This is a huge legacy 
database spanning over 200 tables... but maybe I'll put the three 
largest ones in their own set just for that reason.  The beefy guys are 
about 40M-rows (5-8GB) each, while the little ones probably aren't 
impacting the sync.

> Also, you will want to VACUUM (if not TRUNCATE) those tables to get
> those dead rows out before restarting your slon to try again.

I watched the slony logs.  It's doing a truncate before the initial COPY 
anyway.

> No. Unless you intend to use log shipped replication.

Which you can only do from a primary slave, so no.

I'll experiment with pulling out the larger tables and letting them sync 
on their own.  If that works, we're cool.  If our current server 
weren't 80% full on the disk, I'd just do an on-site convert to 
postgres-8.2 and put the slave in PITR mode until we thought things 
looked good.  Ah well.

-- 

Shaun Thomas
Database Administrator

Leapfrog Online 
807 Greenwood Street 
Evanston, IL 60201 
Tel. 847-440-8253
Fax. 847-570-5750
www.leapfrogonline.com