32-bit to 64-bit migration options

From: Greg Spiegelberg <gspiegelberg(at)gmail(dot)com>
To: "[ADMIN]" <pgsql-admin(at)postgresql(dot)org>
Subject: 32-bit to 64-bit migration options
Date: 2012-02-10 14:45:22
Message-ID: CAEtnbpXugYOAOAup6LxPz3PCPKM=r+jWKSrmXCxN5ELFHNth0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

All,

I'm planning a migration for a customer with a PostgreSQL 8.4 database
cluster running CentOS 4.8 32-bit. The target platform is CentOS 6.2
64-bit and will be running PostgreSQL 8.4 (our application delivers and
supports 8.4, don't bother bringing up 9.x). If this were a small database
cluster I wouldn't worry about it however the 8.4 database cluster is about
900 GB right now. The documented and proper way to move this data is via a
dump-restore however I'm not sure my customer wants days or potentially
weeks of downtime so I'm searching for options.

Option 1: dump-restore
I've performed a handful of these for other customers and even the 100 GB
database cluster using the network transfer method "pg_dumpall | ssh target
-c 'cat - | psql postgres'" can be slow as in 8+ hours.

Option 2: Slony-I
Is Slony-I an alternative when moving data from 32-bit to 64-bit?

Option 3: pg_upgrade
Is this an option? Remember, I'm going from 8.4 32-bit to 8.4 64-bit.

Option 4: PITR
I believe this is not a possibility because of the bit-ness change but I'm
listing anyways in case I'm mistaken.

Did I miss anything?

TIA,
Greg

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Guillaume Lelarge 2012-02-10 15:14:06 Re: 32-bit to 64-bit migration options
Previous Message Lukasz Brodziak 2012-02-10 08:45:19 Segmentation fault/compressed data is corrupted.