[GENERAL] deleting db cluster
Hi, I have a Linux/Debian machine running postgres 8.3 and I need to remove a database cluster that I created with the "initdb" command. Is it enough to just delete the folder in which the cluster resides on the filesystem, or does it require some additional actions? Regards -- Ulas Albayrak ulas.albay...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Re: Moving a live production database to different server and postgres release
Unfortunately, the switch to Windows is out of my hands. If it were up to me I'd stick with BSD. When you say postgres on Windows is known for its "mediocre performance", do you mean it's slower or buggy? Or both? /Ulas On Mon, Jun 14, 2010 at 10:22 PM, Scott Marlowe wrote: > On Mon, Jun 14, 2010 at 7:09 AM, Ulas Albayrak > wrote: >> The database is < 10GB and currently on a postgres version 8.2.15 on a >> BSD system and moving to postgres version 8.4.4 on a windows 2008 >> server. The adding of data is continuous but in small quantities, >> totaling at about 20MB a day. > > Is there are good reason to go to Windows instead of a new BSD system? > Windows is a known mediocre performer for postgres. > > BTW the slony versions need to match down to the minor rev number. > -- Ulas Albayrak ulas.albay...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Re: Moving a live production database to different server and postgres release
OK, I see. Does this mean I need to install Slony-I 1.x on both systems or is different versions of Slony-I, say a 2.x and a 1.x, compatible? The reason I'm asking is because the new server db will be part of a permanent postgres replication system in the future and installing a newer verision of Slony-I would spare me some future work. /Regards On Mon, Jun 14, 2010 at 3:15 PM, Raymond O'Donnell wrote: > On 14/06/2010 14:09, Ulas Albayrak wrote: > >> After your post I had a look at Slony-I, which, according to it web >> page, requires postgres 8.3 or later, so I guess that won't work. That >> leaves Bucardo: will it work on a Windows system? > > AIUI, the Slony-I 2.x branch requires PG 8.3+, but the 1.x branch ill > work perfectly fine on 8.2 and lower. > > This is because 1.x messes with the system catalogues and strange ways, > whereas changes in PG 8.3 made this unnecessary. > > HTH, > > Ray. > > > -- > Raymond O'Donnell :: Galway :: Ireland > r...@iol.ie > -- Ulas Albayrak ulas.albay...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: Moving a live production database to different server and postgres release
The database is < 10GB and currently on a postgres version 8.2.15 on a BSD system and moving to postgres version 8.4.4 on a windows 2008 server. The adding of data is continuous but in small quantities, totaling at about 20MB a day. After your post I had a look at Slony-I, which, according to it web page, requires postgres 8.3 or later, so I guess that won't work. That leaves Bucardo: will it work on a Windows system? /Regards > > My best idea so far is to do a pg_dump and somehow archive all the DML > > in the original db from that point in time for later insertion in the > > new db, but I dont know how that would be done practically. And I > > dont even know if thats the best way to go, as I said, its only an > > idea. > > What you need is a replication system. Take a look at Slony or Bucardo. > Basically, you copy over everything except for the data to the new > database, switch the replication system on, let it catch up, then > stop apps from hitting the server, wait for the new one to catch up, > and point your apps to the new one. > > Important factors that you left out are exactly how big your database is, > what version you are on, what version you are moving to, and how busy your > system is. Also keep in mind that both Bucardo and Slony are trigger based > on primary keys or unique indexes, so tables without such constraints > cannot be replicated: you'll need to either add a unique constraint to > the tables, or copy them separately (e.g. pg_dump -t tablename or > Bucardo's fullcopy mode). > > If you weren't also moving your OS and server, pg_migrator (aka pg_upgrade) > might work for you as well: it does an inplace, one-time upgrade but only > supports a limited number of versions at the moment. > > - -- > Greg Sabino Mullane g...@turnstep.com > End Point Corporation http://www.endpoint.com/ > PGP Key: 0x14964AC8 201006110927 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -- Ulas Albayrak ulas.albay...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Moving a live production database to different server and postgres release
Hi, I'm in the process of moving our production database to a different physical server, running a different OS and a newer release of postgreSQL. My problem is that I'm not really sure how to go about it. My initial idea was to use WAL archiving to reproduce the db on the new server and then get it up to date with the logs from the time of base backup creation to the time the new server can get up. That was until I found out WAL archiving doesn't work between major postgreSQL releases. I can't make a simple pg_dump - pg_restore and then redirect traffic when the new server is up either, because during that time new data will have been inserted in the original db. My best idea so far is to do a pg_dump and somehow archive all the DML in the original db from that point in time for later insertion in the new db, but I don't know how that would be done practically. And I don't even know if that's the best way to go, as I said, it's only an idea. If anyone can give me some ideas on this, I'd be much obliged. Best Regards /Ulas
[GENERAL] Moving a live production database to different server and postgres release
Hi, I’m in the process of moving our production database to a different physical server, running a different OS and a newer release of postgreSQL. My problem is that I’m not really sure how to go about it. My initial idea was to use WAL archiving to reproduce the db on the new server and then get it up to date with the logs from the time of base backup creation to the time the new server can get up. That was until I found out WAL archiving doesn’t work between major postgreSQL releases. I can’t make a simple pg_dump – pg_restore and then redirect traffic when the new server is up either, because during that time new data will have been inserted in the original db. My best idea so far is to do a pg_dump and somehow archive all the DML in the original db from that point in time for later insertion in the new db, but I don’t know how that would be done practically. And I don’t even know if that’s the best way to go, as I said, it’s only an idea. If anyone can give me some ideas on this, I’d be much obliged. Best Regards /Ulas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
