On Thu, Sep 9, 2010 at 8:02 AM, Ulas Albayrak <ulas.albayrak at gmail.com> wrote:
> I'm upgrading from 1.2.21 to 2.0.4, which in other words means I need
> to uninstall the node and delete the old Slony directory before
> installing the new. Setting up a testing environment will be quite a
> big job though, what's the worst thing that can happen if I decide to
> update the live system straight away without testing first? Could it
> interfere with postgresql?

OK.  No matter how much testing you do, you can still have things go
to hell in production.  So, you need to first off be prepared.  Have a
backup machine ready to take over with somewhat out of date (minutes,
hours, whatever) data.  Have a hard backup, preferably both on and off
site. Then, after testing it you can try it in production.

I do initial slony testing on my laptop (either in vms or on the bare
OS).  I don't test on a database as big as production, because I've
only got a 500G drive in this thing.  After proving it basically works
we test it on a bigger machine with more memory and drive space on a
real sized database.  Then we run it on production.

So, what can go wrong?  What's most likely to go wrong?  The most
common failure is that slony simply fails to work and you have to
scrub slony and start over on replication.  Next most common is that
somehow slony breaks in such a way that you cannot use your database
while it's on and running.  Could be something like I had last year
with 2.0.2 or so where it ran fine for a week or two, then the whole
cluster just stopped processing any requests, slony or otherwise until
I removed slony.

The worst possibility is that you would lose your main database server
and all backups.  Try to avoid that.

-- 
To understand recursion, one must first understand recursion.