It does finish, and least I think it does. I will look very carefully this time to make sure (takes a few hours).
This morning I tore the cluster down and recreated it with a different schema name, thinking that might work. I saw the sl_log_1-not-truncated messages and figured it was hosed, so seeing your message that the logswitch can't happen while there is data that needs to be replicated was heartening. (It might be good to make a note in the FAQ that those messages are normal when doing the initial subscribe.) On Thu, Jun 3, 2010 at 7:59 AM, Steve Singer <[email protected]>wrote: > Karl Lehenbauer wrote: > >> Hey... >> >> We have been running slony reasonably effectively for a couple of years >> now. We're on PostgreSQL 8.3, FreeBSD, Slony 2.0.2. >> >> We had this kind of setup. A -> B -> C >> >> B crashed with a weird ethernet problem. It hung us up real bad so in an >> emergency we killed all the slon daemons, shutdown postgresql on C and >> dropped the cluster on A. >> >> Now we're trying to get back going. We have this well documented, did a >> bunch of testing initially, and have done it multiple times successfully in >> the past. You know the drill, plus we have a tool to make sure everything >> has a primary key or an acceptable unique key, generate the slon conf, etc. >> >> We init the cluster, add the set, add the node, subscribe B to A, and we >> start getting... >> >> NOTICE: Slony-I: log switch to sl_log_2 still in progress - sl_log_1 not >> truncated >> > > Does your initial subscribe (the COPY) ever finish? You don't seem to say. > > The logswitch can't happen while there is data that still needs to be > replicated to the other node. If your initial copy hasn't finished yet > then you have rows in sl_log_1 that still need to be replicated, and those > won't replicate until after the copy finishes. > > The other thing that can cause this is if you still have a node subscribed > setup that ins't running any slons (so it isn't confirming events). > > >> OK, so following the Slony FAQ we killed all of our long-running >> connections. No joy. It never straightens itself out. >> >> Finally we killed the slon daemons, dropped the schema, then we shut down >> the database on the primary and start it back up again. We then went >> through the procedure to start up B, subscribe it to A, etc, and again we >> get the error. >> >> I am sure we shut the database down without a slony schema and with no >> slon daemons, started it back up, initialized the cluster, added the set, >> started the slon daemons, but when we subscribe the second node (node 5 by >> the way), it starts giving that notice. >> >> We use the slonik tools and I'm pretty familiar with them. >> >> There can't be any connections with some old cached query plan unless such >> query plans can survive database server restarts. We nuked slony, as we've >> done successfully in the past, and restarted postgres, yet still we get the >> sl_log_1-not-truncated and the table gets huge and then slow. >> >> Can anyone hazard a guess as to what's going on and, better yet, what we >> should do to fix it? >> >> Regards.... >> >> Karl >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Slony1-general mailing list >> [email protected] >> http://lists.slony.info/mailman/listinfo/slony1-general >> > > > -- > Steve Singer > Afilias Canada > Data Services Developer > 416-673-1142 >
_______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
