We had a similar situation last week, 32-bit to 64-bit OS. We decided to keep our PostgreSQL 32-bit (our backup/replication servers are still running 32-bit). We are running it on a 64-bit xen image. We used the package manager to install the 32-bit binaries. Building cross-platform is tricky, so we avoided it. We then did the easy rsync method. With the old DB running, new DB stopped: 1) rsync the /data/ directory 1b) rsync it again (for large DBs, this will get any changes since the long initial rsync) 2) shutdown the old DB 3) final rsync (took us 20 minutes on 5GB) 4) starup new DB Matt -----Original Message----- From: pgsql-admin-owner@xxxxxxxxxxxxxx [mailto:pgsql-admin-owner@xxxxxxxxxxxxxx] On Behalf Of Tino Schwarze Sent: Tuesday, March 30, 2010 9:39 AM To: pgsql-admin@xxxxxxxxxxxxxx Subject: Re: Migrate postgres to newer hardware Hi Renato, dump/restore is the way to go. I suppose, you don't want to compile Postgres for 32 bit on the new machine which might work and might allow you to do the PITR migration. And "downtime is not an option" is always a sign of insufficient planning beforehand. There is no system which doesn't need an upgrade or reboot or whatever, so there will be downtime and it needs to be considered during system analysis. In my experience, it is often just a matter of communicating: "Because of hardware upgrades, the system XYZ will not be available on ..." After all the switch won't be without interruption - you need to switch to the new server anyway. Tino, having migrated a 300+ GB database. On Tue, Mar 30, 2010 at 04:29:29PM +0200, Iñigo Martinez Lasala wrote: > I would follow the ancient method: perform a pg_dump / pg_restore > > Yes, you will have to take offline database for a long period. > > And yes, it would be a great moment to perform a 8.4 upgrade. > Performance is far superior, restore is far faster... > ... and yes, it could give you many problems if you don't perform many > test in order to address all queries without explicit type conversions > before real migration, but I think it's the best moment to deal with a > very convenient upgrade. > > We have performed this upgrade last week with a gforge (with only 25GB > database) and having also to upgrade to new tsearch2 and everything is > running smooth. > > -----Original Message----- > From: Renato Oliveira <renato.oliveira@xxxxxxxxxxx> > To: pgsql-admin@xxxxxxxxxxxxxx <pgsql-admin@xxxxxxxxxxxxxx> > Subject: Migrate postgres to newer hardware > Date: Tue, 30 Mar 2010 12:18:36 +0100 > > Dear All, > > > > What would be the easiest and fastest way to migrate Postgres 8.2.24 32 > BIT to a new server 64 Bit. > > > > The existing server runs on 32 bit architecture and has a database as > big as 160GB. > > > > We initially thought of using PITR, but as one of the PITR requirements > is both machines need to be similar. > > This similarity needs to be even in architecture? I think I read > something which says “Yes”. > > > > If we cannot use PITR what would be the best approach, we can’t have > down time I am afraid. > > > > Any ideas or suggestions would be very welcome. > > > > Thank you very much > > > > Best regards > > > > Renato > > > > > > > > Renato Oliveira > Systems Administrator > e-mail: renato.oliveira@xxxxxxxxxxx > > Tel: +44 (0)1763 260811 > Fax: +44 (0)1763 262410 > www.grant.co.uk > > Grant Instruments (Cambridge) Ltd > > Company registered in England, registration number 658133 > > Registered office address: > 29 Station Road, > Shepreth, > CAMBS SG8 6GB > UK > > > > > > > > > > P Please consider the environment before printing this email > > > CONFIDENTIALITY: The information in this e-mail and any attachments is > confidential. It is intended only for the named recipients(s). If you > are not the named recipient please notify the sender immediately and do > not disclose the contents to another person or take copies. > > > VIRUSES: The contents of this e-mail or attachment(s) may contain > viruses which could damage your own computer system. Whilst Grant > Instruments (Cambridge) Ltd has taken every reasonable precaution to > minimise this risk, we cannot accept liability for any damage which you > sustain as a result of software viruses. You should therefore carry out > your own virus checks before opening the attachment(s). > > > OpenXML: For information about the OpenXML file format in use within > Grant Instruments please visit our website > -- "What we nourish flourishes." - "Was wir nähren erblüht." www.lichtkreis-chemnitz.de www.tisc.de -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
