Re: [Slony1-general] Re: Stripping out slony after / before / during pg_restore? - Mailing list pgsql-general

From Stuart Bishop
Subject Re: [Slony1-general] Re: Stripping out slony after / before / during pg_restore?
Date
Msg-id 6bc73d4c0810130305q7c522e40v66a765877ee359e0@mail.gmail.com
Whole thread Raw
In response to Re: [Slony1-general] Re: Stripping out slony after / before / during pg_restore?  (Christopher Browne <cbbrowne@ca.afilias.info>)
Responses Re: [Slony1-general] Re: Stripping out slony after / before / during pg_restore?
List pgsql-general
>>> I'm setting us up a separate staging / test server and I want to read
>>> in a pg_dump of our current origin stripping out all the slony stuff.
>>>
>>> I was thinking this could serve two purposes a) test out backups
>>> restore properly and b) provide us with us with the staging / test
>>> server
>>>
>>> What's the best way to remove all the slony bits?
>>
>> Well, you can always just drop the slony schema (with a cascade) -
>> that should do it.
>
> Not quite.  There are two things that *doesn't* hit:

So what was the final recommended process for building a stand alone
database from a pg_dump of a replicated node?

pg_dump --oids --format=c --file=master.dump master_db
createdb staging_db
pg_restore -d staging_db master.dump
slonik << EOM
cluster name = sl;
node 1 admin conninfo = 'dbname=staging_db user=slony';
uninstall node (id = 1);
EOM

This process dies on the last step with:

<stdin>:3: PGRES_FATAL_ERROR select "_sl".uninstallNode();  - ERROR:
Slony-I: alterTableRestore(): Table with id 1 not found
CONTEXT:  SQL statement "SELECT  "_sl".alterTableRestore( $1 )"
PL/pgSQL function "uninstallnode" line 14 at PERFORM
Failed to exec uninstallNode() for node 1

So if I'm reading this thread correctly, the alternative is 'DROP _sl
CASCADE;', which doesn't do a full cleanup. Is there no supported
disaster recovery procedure?

--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/

pgsql-general by date:

Previous
From: "Ang Chin Han"
Date:
Subject: Re: [PERFORM] Drupal and PostgreSQL - performance issues?
Next
From: Greg Smith
Date:
Subject: Re: Opteron vs. Xeon performance differences