On Tue, Aug 26, 2008 at 5:39 AM, Phoenix Kiula <phoenix.kiula@gmail.com> wrote:
>>
>> You need to download Slony 1.2.14, which supports both 8.2 and 8.3.
>> You'll find it under Quick downloads.
>>
>
>
>
> Ok done. Slony is installed. Now what? How should I install a new
> database which is 8.3.3?

Which OS are you running? How was 8.2 installed?

> I was also told that the postgresql.conf settings across 8.2 and 8.3
> are different so I cannot (or should not) use the same old
> postgresql.conf for the new database install. Is this true? Where can
> I find the instructions? I read this lengthy document --
> http://www.postgresql.org/docs/8.3/s...lease-8-3.html -- but it
> is not clear which variables I need to change.

Well, look at the entries that aren't commented out in your 8.2 and
make the same changes in your 8.3 postgresql.conf

I just want to point out that the reason there aren't a lot of step by
step guides on this is that it's a complex subject. There are many
different OSes and several ways you could have installed postgresql,
and step by step instructions for RHEL4 may not be the same as for
Ubuntu 8.04 etc...

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Tue, Aug 26, 2008 at 6:31 AM, Phoenix Kiula <phoenix.kiula@gmail.com> wrote:
> On 8/26/08, Tomasz Ostrowski <tometzky@batory.org.pl> wrote:
>>
>> I think nobody would guide you step by step. Either read documentation
>> and do it yourself or hire an expert:
>
>
> Thanks. I suppose that spirit is quite evident in the documentation.
> Why make it easy or easily understandable when you can win fanatical
> fans by requiring them to invest months of their time!

Christ, remind to do you no favors. I'm sure if I had written a step
by step guide and one part of it didn't work you'd be right back here
threatening to sue me or something.

Look, it's a comlex subject, and you need to have a pretty good clue
what you're doing so if something goes wrong you're not making a big
mistake and losing all your data. And you can stop with the
histrionics. It took me less than one weekend to install and test
slony for migration / backup at work.

Remember, for every problem, there is a simple, elegant, easy
solution. Which is wrong.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

phoenix.kiula@gmail.com ("Phoenix Kiula") writes:
> See, this is where I get confused. I want to upgrade from 8.2.3 to
> 8.3.3. The recommendation is to try Slony. So I download Slony and try
> to configure it. The configure command gives me this:
>
>
> ----
> checking for correct version of PostgreSQL... "error"
> configure: error: Your version of PostgreSQL (8.2) is lower
> than the required 8.3. Slony-I needs functionality included in
> a newer version.
> ----
>
>
> Well, if Slony needs a newer version, then how can it be used to upgrade?!

I expect that what you downloaded was a pre-release candidate for
version 2.0, which does indeed "eschew" older versions (for some good
reasons - you can't support *all* versions of *everything*,
*forever*).

With version 1.2.14, the latest *official* release, versions of
PostgreSQL as far back as 7.4 are certainly supported.
--
output = reverse("moc.enworbbc" "@" "enworbbc")
http://cbbrowne.com/info/lsf.html
Dickson's Gardening Rule: When weeding, the best way to make sure you
are removing a weed and not a valuable plant is to pull on it. If it
comes out of the ground easily, it is a valuable plant.

phoenix.kiula@gmail.com ("Phoenix Kiula") writes:
> On 8/26/08, Tomasz Ostrowski <tometzky@batory.org.pl> wrote:
>>
>> I think nobody would guide you step by step. Either read documentation
>> and do it yourself or hire an expert:
>
> Thanks. I suppose that spirit is quite evident in the documentation.
> Why make it easy or easily understandable when you can win fanatical
> fans by requiring them to invest months of their time!

I think that the level of detail that we *DID* give in the page on
version upgrades was not unsuitable.
http://www.slony.info/documentation/versionupgrade.html

It doesn't try to explain *EVERYTHING*; it tries to give enough detail
to help you construct whatever procedure you need to construct.

The trouble with it all is that:

a) Flexibility comes at a cost, namely the cost of there being some
not-inconsiderable complexity.

Unfortunately, it's not easy, and wishing it were so is just
wishful thinking.

I wish it *could* be easy, but it simply isn't, and I don't see
anything to change that *would* make it easy.

b) People are using different sorts of environments that can vary
quite a bit.

This means that if we write up a super-detailed procedure, that
procedure will ONLY be valid for the specific environment it was
written for.

For instance, I could go into gratuitous detail about how to do
PostgreSQL and Slony-I compiles and installs on our AIX systems,
unfortunately, that detail would NOT be useful to you when you're
using something else.

If, instead, I went into deep detail as to how to deal with a
2-node cluster on Ubuntu Linux, in conjunction with CPanel, this
would:

a) Not be relevant to our staff that aren't using that flavour of
Linux, and
b) Have portions that are totally irrelevant to anyone not using
CPanel.

Super-detailed procedures aren't worth having, sorry.
--
(format nil "~S@~S" "cbbrowne" "linuxfinances.info")
http://linuxfinances.info/info/advocacy.html
"Be warned that typing ``killall name'' may not have the desired
effect on non-Linux systems, especially when done by a privileged
user." -- From the killall manual page

On Tue, Aug 26, 2008 at 12:10 AM, Phoenix Kiula <phoenix.kiula@gmail.com> wrote:
> On 8/26/08, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>>
>> Slony replication lets postgresql accomplish this, which is really
>> quite impressive. We just upgraded from an 8.1 server to an 8.3
>> server via slony, and it went smooth as silk. db downtime was
>> measured in seconds.
>
> Thanks for this Scott. Sounds promising. But where can I find the
> instructions to install Slony, then install new PG 8.3.3, then start
> it with similar CONF settings and stuff, then setup the master and
> slave (which I am not familiar with), and then switch master and slave
> when everything is working?

Problem here is that while each piece of the puzzle probably has it's
own useful instructions, no one has put them all together into one
document, and the reason for that is choice. With a choice of
versions to be upgrading from and to, options of whether or not you
need to replicate and entire database or not, versions of slony, and
ways to install each version of pgsql on each of those different OSes,
it's hard to make documents that don't start with "This thing was only
test with pgsql v7.4.7 to v8.0.3 with slony 1.2.09 on RHEL 3.

Suddenly you've got a guide that's 3 years old and most of the info in
it is now not the right thing to do if you're upgrading from 8.1.4 to
8.3.3 with slony 1.2.14 and could cause you problems. I used to write
docs like that for my last company, and within a year or two they're
useless.

> To others who keep telling us that "PG is complex and if you want it
> to be less so then contribute" -- well, sorry I am not that technical.

Then you should find someone in your neighborhood who's been busy
learning pgsql on an intranet and wishing he could build a production
system on it and hire him. Or something like that. Or become a
little bit of him.

Note that you can also contribute by whipping out your checkbook and
hiring one of the hackers who regularly work on pgsql to implement
something. It's how Slony got started. Thanks Afilias and folks.

> If the intended target audience of PG is only super-techsavvy folk who
> can write C++ patches for every little functionality they need, then
> perhaps I chose the wrong DB? I doubt it.

No, I don't think that's entirely the case. If you need a corporate
office db to handle a few thousand users a dozen at a time, with
weekend down time and a small to medium database I'm pretty sure my
mom could keep the machine happy.

But if you're running a 24/7 no down time outside of scheduled
maintenance db with high load then you're not going to find something
that just bolts in and works. In some ways PostgreSQL is actually
pretty close. But you're gonna have to at least learn how to plug it
into Nagios or something.

If you then need a 365.25 system with no down days, no scheduled
maintenance, you've reached the point where the air is thin and the
cost of doing in business gets high. Entire applications were written
in the past to migrate living databases. Slony is one of the slickest
replication tricks I've ever seen when it comes to the ability to
upgrade in place. You do it once every 1 to 4 years, so it takes
planning and testing.

Build a test environment, using Xen if you don't have enough physical
machines and need virtual ones, and make sure you understand what's
happening and catch your simple mistakes. Then backup production and
try it there. But testing is key.

> It would be really nice if the PG official community can have some
> simple instructions to make a seamless upgrade, if no simpler patches
> exist.

You're as official as me or anybody else.

> At the very least the instructions will help us plentiful folk
> who do NOT use PG in the exalted "enterprise" setting, but to run busy
> websites.

Well, if you can't be down for a saturday morning from 0000hrs to
0800hrs then you are indeed in the exalted enterprise setting.

> This is how MySQL became big too, by being convenient and
> reliable (until recently anyway), but I see no point in that
> discussion.

Some could argue they're a victim of their own success. They were
stuck supporting old version for far too long, and spent a lot of
energy trying to make things easy, but many of those things, like
replication, aren't actually guaranteed to work. Add in the system
catalogs are stored in myisam table and your whole replicated innodb
based system could get corrupted because it was replicating DDL when
the power went out. Slony is built, like the rest of pgsql, to
survive the power going out.

> Anyhow, it would be really nice to have simple instructions. Searching
> on Google for words like "Slony Postgresql upgrade" or "install slony
> with postgresql 8.3" returns stuff that makes a lot of presumptions!

Well, throw at us what you got and what you got questions about.

> I have a CentOS 4 with Cpanel/WHM running. PG is in the usual place:

I'm running Centos 5. Using yum / rpm to update packages, admin from
the cmd line.

Here's a major issue with Centos and redhat derivatives: Their
packaging system can't directly support two versions of pgsql on the
same machine.

So, if you're running Centos, you have two choices, have two choices.
Use two db servers, or compile at least one version of pgsql from
source. When I ran RHEL4 I had two machines, but I still built pgsql
from source because this was right before slony was available as rpm
for my pgsql / rhel version. Also had to build php from source cause
we Oracle. So I figured I'd just build them all from source. Worked
fine, and with --prefix I put them into pg73 pg81 pg82 directories
and compiled them all against each other.

But with my current production setup, I can take the backup
replication server offline, upgrade pgsql, and replicate from the
older version to the newer. Then switch, take the old master / new
slave offline, upgrade it, replicate, switch, tada! I'm done. I
still build slony from source on Centos, but nothing else.

You could do the same thing with ubuntu or debian, but without any
compiling and on one machine, since debian and it's children support >
1 version of pgsql on the same machine and have slony packages for
them too. If you want pgsql 8.3 AND slony for it you'll need ubuntu
8.04.01. But I don't trust that OS in production yet.

> > whereis pgsql
> pgsql: /usr/lib/pgsql /usr/include/pgsql /usr/share/pgsq
>
> Now how can I install Slony so that it install PGSQL and allows me to
> continue working with Apache/PHP for my website? I am reading this --
> http://slony.info/documentation/installation.html -- but while it
> textually mentions the stuff in the writeup, I don't see full
> instructions to install Slony, then new PGSQL, then switching, and so
> on.

It's very distro dependent. It's not really "our" job how you have to
install on your OS. It's your OSes job. With Centos you'll either be
looking for the proper slony rpms, if available, or building from
source. If you're building slony from source, you'll need the -devel
packages for pgsql. php won't be affected.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Aug 26, 2008, at 10:22 AM, Scott Marlowe wrote:

> On Tue, Aug 26, 2008 at 12:10 AM, Phoenix Kiula <phoenix.kiula@gmail.com
> > wrote:
>> On 8/26/08, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>>>
>>> Slony replication lets postgresql accomplish this, which is really
>>> quite impressive. We just upgraded from an 8.1 server to an 8.3
>>> server via slony, and it went smooth as silk. db downtime was
>>> measured in seconds.
>>
>> Thanks for this Scott. Sounds promising. But where can I find the
>> instructions to install Slony, then install new PG 8.3.3, then start
>> it with similar CONF settings and stuff, then setup the master and
>> slave (which I am not familiar with), and then switch master and
>> slave
>> when everything is working?
>
> Problem here is that while each piece of the puzzle probably has it's
> own useful instructions, no one has put them all together into one
> document, and the reason for that is choice. With a choice of

Phoenix, you might want to start with some hands on postgres training
to quickly get up to speed on slony. I've used http://www.otg-
nc.com/ . They are very good.

Bob

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general