Re: Migrate postgres to newer hardware - Mailing list pgsql-admin

On Tue, 2010-03-30 at 12:36 +0100, Renato Oliveira wrote:
> 
> Szymon,
>
>
>
> We had Slony running previously, but it lagged behind so badly that
> never managed to catch up.
>
>
>
> Hardware
>
> AMD 1.8GHz 32 Bits
>
> 8GB RAM DDR1
>
> 300GB Disk single volume
>
>
>
> Database:
>
> Postgres 8.2.24
>
> 160GB in size
>
> There are thousands of tables, apparently for each new device a new
> table is created.

I *think* I remember reading a while back case on the Slony list that
some of the internal queries where not very efficient for databases with
large numbers of tables.
>
> The DB  grows around 1GB every 2 days.

That's not material.  We use slony replicate much larger databases with
a higher growth rate than that.
>
> Do you still think slony would work?

It might, it might not.  I'd ask for assistance on the Slony list.

Also, Londiste is another replication engine that can be used for DB
upgrades.

>
> Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@grant.co.uk
>
> 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
>
>
>
> From: Szymon Guz [mailto:mabewlun@gmail.com]
> Sent: 30 March 2010 12:29
> To: Renato Oliveira
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Migrate postgres to newer hardware
>
>
>
>
>
>
> 2010/3/30 Renato Oliveira <renato.oliveira@grant.co.uk>
>
> 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.
>
>
>
>
>
>
>
> I'd use Slony as a replication tool so the data would be copied to the
> new serwer while the old still works. After initial copy Slony will
> copy changes made during making the copy. Later (when the replication
> lag is small) it should be enough to stop application, reconfigure it
> for the new database, get rid of replication so the new slave database
> will restore all triggers and then start the application for using the
> new database.
>
>
> Slony uses pure SQL for copying the data so there is no problem with
> the differences in the hardware.
>
>
>
>
>
> regards
>
>
> Szymon Guz
>
>
>
>
>
>
>
> 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
--
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.