On 3/6/2013 3:24 PM, Jonathan Soong wrote:
> Hi Jan
>
> Sorry for not including version, yup im 2.0.7 and pg 8.4.11.
>
> That's good, at least I know no data has been corrupted.

Indeed, that is a good thing.

>
> As you say, I think DDL was run against the Slave by itself and i think it is corrupted. I don't think i can repair it because things were done against the Slave since then.

Well, have you tried to run the REPAIR CONFIG slonik command for the set 
against the slave? The damage may not be as severe as you think.

What is the actual name of that sequence 10 according to sl_sequence? 
Does that sequence exist in the slave database?


>
> I am presuming the UNINSTALL NODE will bypass the slony event queue (which is blocked up with an error) ?

UNINSTALL NODE is a command that actually removes all traces of Slony 
from a database. There should not be a slon daemon running at that time 
and you are left with a standalone database, that has no idea what Slony 
is at all.

Both databases would still have all your tables with whatever data is 
currently in them.

So you would stop the slon daemons, run UNINSTALL NODE against both, 
master and slave. Then rebuild your replication from scratch, just 
assuming that you don't have to copy any schema. The tables already 
exist on the slave, so there is not need to do that.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin