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 _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
