On 8/2/07, Jeff Frost <[EMAIL PROTECTED]> wrote: > > Andrew, thanks for the response! My responses are inline below: > > On Thu, 2 Aug 2007, Andrew Hammond wrote: > > > On 7/30/07, Jeff Frost <[EMAIL PROTECTED]> wrote: > >> > >> Hi folks, > >> > > I bet you took the short-cut of not dropping the database and reloading > a > > fresh schema. Simply dropping the _slony schema with cascade is _not_ > > sufficient on subscriber nodes. > > That's only an issue on subscriber nodes, right? No worries there because > I > also upgraded it to 8.2.4, so it had to be re-initdb'd, the db created and > the > schema copied over from the master.
Correct, this is only an issue on nodes which are subscribed to 1 or more sets. > >> Except, I don't know why it's looking in /usr/lib64/pgsql because this > is > >> a 32 > >> bit CentOS 4.3 machine. I double checked that the i686 versions of > >> postgres > >> are installed, slony was compiled from source against > /usr/bin/pg_config > >> which > >> correctly outputs that libdir is /usr/lib/pgsql: > >> PKGLIBDIR = /usr/lib/pgsql > >> > >> What am I missing? Is there a special procedure for using > >> Postgresql-8.2.4? > > > > > > Sounds like your build is broken. > > I would agree, except that running strings against the postgresql binaries > that I cpio'd out of the 8.2.4 RPMs yields no lib64. So I'm still not > entirely sure what's going on there. They are the community RPMs, so I > would > think someone would have noticed by now. Also, fgrep -r lib64 through the > slony source after the configure yielded no results as well. There is no reason to expect lib64 to appear in the source. If it appears in your binary, then some part of your build is targeted at a 64bit machine. I can't speak for anything involving the RPMs. I don't use them. I build from source. Since slony is a relatively young piece of code, we continue to find and patch bugs at a relatively high pace. Not building from scratch may get you into a sticky situation in production where you need a patched version and it is not available as a package. > > > It yielded the same results with slony 1.2.8 and 1.2.9. But, 1.2.10 is > >> working fine with postgresql-8.1.9 which we reverted to. > > > > > > I'm a little confused as to why you would conflate a database upgrade > with a > > replication upgrade. The usual process (or at least the one I've > regularly > > used) is as follows. > > > > Neat! I learned a new word (conflate). :-) The reason for this > methodology > was just speed. Also, we were loading a dump from the production master > (this > is the QA slony cluster) to bring it up to date before applying the new > version changes. There wasn't any need to keep the slave in use, so we > tried > to do more than one thing at a time. I'd expect that a migration process is something you'd want to test in QA before you did it in production... I (erroneously?) thought that starting from a production dump with the > _slony > schema dropped cascade should work fine for resubscribing, but apparently > that's not the case. I'm not sure I understand why that is > though. Doesn't a > drop cascade of the _slony schema on the master remove every bit of slony > tables, functions, etc? It should work fine on pg_dumps that are from the a database that doesn't subscribe to any sets (an origin-only system). > 1) Upgrade cluster to latest slony (assuming you plan to upgrade slony) > > 2) add a new node, running on the new version of PostgreSQL > > 3) make sure you're happy with the new node > > 4) promote new replica to origin > > > > For each old node, > > 1) drop old node from replication > > 2) re-initdb with newest postgresql binary > > 3) subscribe new node to cluster > > Soon as we get a duplicate environment for this, we'll try that method as > well. > Hmm, a QA environment doesn't have to be identical to production unless you intend to do test load / scaling issues. It only needs to be representative.
_______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
