Thread: Easy upgrade on Cpanel *without* downtime
Hi. I have googled and googled for good, simple instructions to upgrade from 8.2.3 to 8.3.3 (latest stable at this time?) I am on a Cpanel interface. Use Apache and PHP for most of my websites. This seems to be the most often quoted resource on forums etc: http://kb.linuxnetworkcare.com/node/21 But this suggests backing up, then UNinstalling (downtime and loss of settings!), then REinstalling postgresql. Is there no sensible way of simply upgrading the database engine without affecting either the uptime or the data itself? I really really do not wish to backup gigabytes worth of data and then reupload it back into the DB. This represents a downtime of *at least* an hour or so, which our busy website doesn't have. Any thoughts or pointers? Thanks!
Hi, Phoenix Kiula wrote: > Hi. > > I have googled and googled for good, simple instructions to upgrade > from 8.2.3 to 8.3.3 (latest stable at this time?) > > I am on a Cpanel interface. Use Apache and PHP for most of my websites. > > This seems to be the most often quoted resource on forums etc: > > http://kb.linuxnetworkcare.com/node/21 > > But this suggests backing up, then UNinstalling (downtime and loss of > settings!), then REinstalling postgresql. > > Is there no sensible way of simply upgrading the database engine > without affecting either the uptime or the data itself? > > I really really do not wish to backup gigabytes worth of data and then > reupload it back into the DB. This represents a downtime of *at least* > an hour or so, which our busy website doesn't have. > > Any thoughts or pointers? The usual way to do it and to avoid downtime is to install the new version along the old one, backup/restore as usual (e.g. pg_dump | pg_restore to avoid wasting space 2 times) then run slony to permanently update the last bits while you are checking settings and performance of the new version. If everything is fine, use a calm moment to switch your configuration to use the new database in production. Regards Tino
Attachment
Normally we don't use the packages from the distributions. They're mostly outdated and installation ov two or more versions of Postgres isn't that easy normally in this case. We've a directory structure which allows us to install and startup two or more versions in parallel. I haven't tried this but if you have two instances running (one 8.2 and the thoer 8.3) you can try to install Slony migrating all the data through replication. When all data is synchronized a shot downtime is needed to switch between the two versions. Maybe this is a way to go... Robert Phoenix Kiula wrote: > Hi. > > I have googled and googled for good, simple instructions to upgrade > from 8.2.3 to 8.3.3 (latest stable at this time?) > > I am on a Cpanel interface. Use Apache and PHP for most of my websites. > > This seems to be the most often quoted resource on forums etc: > > http://kb.linuxnetworkcare.com/node/21 > > But this suggests backing up, then UNinstalling (downtime and loss of > settings!), then REinstalling postgresql. > > Is there no sensible way of simply upgrading the database engine > without affecting either the uptime or the data itself? > > I really really do not wish to backup gigabytes worth of data and then > reupload it back into the DB. This represents a downtime of *at least* > an hour or so, which our busy website doesn't have. > > Any thoughts or pointers? > > Thanks! > >
On Mon, Aug 25, 2008 at 11:34:00AM +0200, Tino Wildenhain wrote: > (e.g. pg_dump | pg_restore to avoid wasting space 2 times) > then run slony to permanently update the last bits If you're going to run slony, then the pg_dump|pg_restore step is completely wasted. Slony will restore all the data again. You do need to run pg_dump -s, of course. A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
Andrew Sullivan wrote: > On Mon, Aug 25, 2008 at 11:34:00AM +0200, Tino Wildenhain wrote: >> (e.g. pg_dump | pg_restore to avoid wasting space 2 times) >> then run slony to permanently update the last bits > > If you're going to run slony, then the pg_dump|pg_restore step is > completely wasted. Slony will restore all the data again. You do > need to run pg_dump -s, of course. good point :-) Regards Tino
Attachment
> > If you're going to run slony, then the pg_dump|pg_restore step is > > completely wasted. Slony will restore all the data again. You do > > need to run pg_dump -s, of course. Thanks to everyone who replied. We have no experience with this "Slony". Any simple instructions on installing it and getting it working? Why is PG so complex! It's a such a lovely database. If only at least the installation and upgrade could be made more humane..
On Tue, 26 Aug 2008 09:25:09 +0800 "Phoenix Kiula" <phoenix.kiula@gmail.com> wrote: > "Slony". Any simple instructions on installing it and getting it > working? > > Why is PG so complex! It's a such a lovely database. If only at least > the installation and upgrade could be made more humane.. > Well the installation is about as easy as it gets. I grant you we are in the stone age when it comes to upgrading. We are however welcoming patches should you feel the need to create and or sponsor :) Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Mon, Aug 25, 2008 at 7:25 PM, Phoenix Kiula <phoenix.kiula@gmail.com> wrote: >> > If you're going to run slony, then the pg_dump|pg_restore step is >> > completely wasted. Slony will restore all the data again. You do >> > need to run pg_dump -s, of course. > > > > > Thanks to everyone who replied. We have no experience with this > "Slony". Any simple instructions on installing it and getting it > working? > > Why is PG so complex! It's a such a lovely database. If only at least > the installation and upgrade could be made more humane.. Any database that has real ACID guarantees is going to be complex. Some more than others. I think that upgrading postgresql in place is a LOT of work and not the highest priority, and slony lets you upgrade LIVE. Note that you cannot upgrade an Oracle installation from 9g to 10i live. You take it offline from the app, migrate your data, and start up the new database. 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.
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? 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. 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. 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. 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. This is how MySQL became big too, by being convenient and reliable (until recently anyway), but I see no point in that discussion. 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! I have a CentOS 4 with Cpanel/WHM running. PG is in the usual place: > 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. So many thanks for any help anyone can provide! Or point me to some resource that exists but is hiding from Google.
On 8/26/08, 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? > > 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. > 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. > > 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. 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. This is how MySQL became big too, by being convenient and > reliable (until recently anyway), but I see no point in that > discussion. > > 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! > > I have a CentOS 4 with Cpanel/WHM running. PG is in the usual place: > > > 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. > > So many thanks for any help anyone can provide! Or point me to some > resource that exists but is hiding from Google. > 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?!
Phoenix Kiula wrote: > On 8/26/08, 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? >> >> 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. >> 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. >> >> 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. 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. This is how MySQL became big too, by being convenient and >> reliable (until recently anyway), but I see no point in that >> discussion. >> >> 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! >> >> I have a CentOS 4 with Cpanel/WHM running. PG is in the usual place: >> >> > 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. >> >> So many thanks for any help anyone can provide! Or point me to some >> resource that exists but is hiding from Google. >> > > > > 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?! It looks like you have downloaded Slony 2.0.0RC1, which has in it's release notes "It drops all support for databases prior to Postgres version 8.3. ". It's also just a release candidate, not an actual release. You need to download Slony 1.2.14, which supports both 8.2 and 8.3. You'll find it under Quick downloads. //Magnus
> > 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? 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/static/release-8-3.html -- but it is not clear which variables I need to change. Thanks.
On 2008-08-26 13:39, Phoenix Kiula wrote: > Ok done. Slony is installed. Now what? http://www.slony.info/documentation/versionupgrade.html I think nobody would guide you step by step. Either read documentation and do it yourself or hire an expert: http://www.postgresql.org/support/professional_support > 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. Find out what changes were made to your old postgresql.conf (compare it to the default) and make the same changes to new posgresql.conf. Regards Tometzky -- ...although Eating Honey was a very good thing to do, there was a moment just before you began to eat it which was better than when you were... Winnie the Pooh
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! Cheers.
On Tue, Aug 26, 2008 at 5:02 AM, Tomasz Ostrowski <tometzky@batory.org.pl> wrote: > http://www.slony.info/documentation/versionupgrade.html > I think nobody would guide you step by step. Well they may, then is nothing wrong with asking especially when "breaking new ground." Since my databases are currently pretty small, a dump and reload is not a problem. However, I am following this tread with keen interest for future reference. Perhaps others are also? > Either read documentation > and do it yourself or hire an expert: > http://www.postgresql.org/support/professional_support Reading the documentation is always good advice. Ofcourse, I think that DBA/SA wants and should be able to perform all tasks associated with maintaining a database. However, I very much agree that buying a support aggreement for "mission critical" applications is an important safety net to have. > Find out what changes were made to your old postgresql.conf (compare it > to the default) and make the same changes to new posgresql.conf. I very much agree. There wasn't that much that changed between 8.2 and 8.3. Just look for the uncommented postgresql.conf setting in 8.2 and then compare with 8.3. -- Regards, Richard Broersma Jr. Visit the Los Angeles PostgreSQL Users Group (LAPUG) http://pugs.postgresql.org/lapug
On Mon, Aug 25, 2008 at 08:36:34PM -0600, Scott Marlowe wrote: > Slony replication lets postgresql accomplish this, which is really > quite impressive. Pleased as I am to hear accounts of Slony being used successfully to solve the upgrade problem -- it was one of our design goals in the early discussions at Afilias -- I have to confess that if you find Postgres administration arcane, Slony administration is going to seem very like interpreting runes. I have heard that Londiste (in the skytools package) can also do this, and it is intended to be easier to administer. I have no personal experience trying it. A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
On Tue, Aug 26, 2008 at 5:31 AM, Phoenix Kiula <phoenix.kiula@gmail.com> wrote: > I suppose that spirit is quite evident in the documentation. All kidding aside, the problem that you are having IS recognized as a weakness with PostgreSQL. This is why some are already working on solving the problem of in place upgrades. Some time in the future perhaps > 8.4 this will be a mute point. In the meantime, there are other workarounds (which of course can be complex) to mitigate this problem. > Why make it easy or easily understandable when you can win fanatical > fans by requiring them to invest months of their time! I sense your frustration. But it is important to remember that the PostgreSQL project is largely supported by volunteers. I am sure that you agree that no one intentionally designs any give task to be more complicated than necessary. As a side note there are many useful "how to" articles on the web. Many of these HOWTOs were created by users (like yourself) that have faced a difficult problem with no apparent solution. However, after struggling with the problem and then finding a solution, they document it for all to benefit from. Perhaps some good with come from overcoming this challenge. So in the mean time, the best advice is not to rush time upgrade but take your time to insure that you do it right the first time. Some useful article that you should consider are: http://www.depesz.com/index.php/2008/05/05/error-operator-does-not-exist-integer-text-how-to-fix-it/ http://people.planetpostgresql.org/greg/index.php?/archives/136-Upgrading-to-8.3-MediaWiki-lessons-learned.html -- Regards, Richard Broersma Jr. Visit the Los Angeles PostgreSQL Users Group (LAPUG) http://pugs.postgresql.org/lapug
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/static/release-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...
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.
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.
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.
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 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