From: | "Stuart Bishop" <stuart(at)stuartbishop(dot)net> |
---|---|
To: | slony1-general(at)lists(dot)slony(dot)info, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [Slony1-general] Re: Stripping out slony after / before / during pg_restore? |
Date: | 2008-10-13 10:05:21 |
Message-ID: | 6bc73d4c0810130305q7c522e40v66a765877ee359e0@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)stuartbishop(dot)net>
http://www.stuartbishop.net/
From | Date | Subject | |
---|---|---|---|
Next Message | arnuld uttre | 2008-10-13 10:17:01 | Re: user and DB confusion |
Previous Message | Grzegorz Jaśkiewicz | 2008-10-13 09:45:09 | Re: user and DB confusion |