:pgsql-admin-ow...@postgresql.org] On Behalf Of Iñigo Martinez Lasala
Sent: 02 April 2010 08:41
To: Brad Nicholson
Cc: pgsql-admin
Subject: Re: [ADMIN] Migrate postgres to newer hardware
I would never sing a SLA for HA if I don't have system, at least, fully
redundant in order to deal with t
On Fri, 2010-04-02 at 09:58 +0200, Iñigo Martinez Lasala wrote:
> I've never worked with Bucardo and Londiste, so I cannot give you any
> hint about it.
> With slony it's not necessary to restore all database prior staring
> sync process. You only have to restore your schema but not data. Slony
> w
On Fri, Apr 2, 2010 at 1:58 AM, Iñigo Martinez Lasala
wrote:
> I've never worked with Bucardo and Londiste, so I cannot give you any hint
> about it.
> With slony it's not necessary to restore all database prior staring sync
> process. You only have to restore your schema but not data. Slony will
ge-
From: Renato Oliveira
To: Iñigo Martinez Lasala
Cc: pgsql-admin
Subject: RE: [ADMIN] Migrate postgres to newer hardware
Date: Wed, 31 Mar 2010 09:11:37 +0100
Hi Iñigo,
Thank you for your input, really appreciated.
I just had a thought; if I backup ‘pg_dump’ full database, t
grate postgres to newer hardware
Date: Tue, 30 Mar 2010 10:38:02 -0400
On Tue, 2010-03-30 at 16:29 +0200, Iñigo Martinez Lasala wrote:
> Hi Renato.
>
> I would follow the ancient method: perform a pg_dump / pg_restore
This is the easiest approach. The problem is that a lot of people ha
Renato Oliveira wrote:
I am going to gather the figures about our database and I will email to the
list, if I am allowed to.
Number of tables, number of transactions per day etc.
A quick snapshot from "vmstat 1" during a busy time is also very helpful.
--
Greg Smith 2ndQuadrant US Baltim
On Wed, 2010-03-31 at 09:22 +0100, Renato Oliveira wrote:
> Greg,
>
> I am going to gather the figures about our database and I will email to the
> list, if I am allowed to.
> Number of tables, number of transactions per day etc.
Absolutely allowed, and encouraged.
Also, do you have long runni
On Tue, Mar 30, 2010 at 10:07:54PM -0400, Dai, Tino wrote:
> I'm not a dba. I'm a sysadmin by training. Is there some way to
> mirror the disks at the OS level? And then move it to the new
> machine. Just a though, I don't know the exact steps. But if you
> are interested,
: Renato Oliveira
Cc: Greg Smith; Tino Schwarze; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Migrate postgres to newer hardware
On Wed, Mar 31, 2010 at 1:43 AM, Renato Oliveira
wrote:
> Greg,
>
> Thank you very much for your input.
> I agree with you and I do understand where you are
office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
From: Iñigo Martinez Lasala [mailto:imarti...@vectorsf.com]
Sent: 30 March 2010 16:27
To: Renato Oliveira
Cc: pgsql-admin
Subject: RE: [ADMIN] Migrate postgres to newer hardware
Yes, you only have that two possibilities, I think.
PITR
On Wed, Mar 31, 2010 at 1:43 AM, Renato Oliveira
wrote:
> Greg,
>
> Thank you very much for your input.
> I agree with you and I do understand where you are coming from.
>
> I do agree that in order to transition without a noticeable downtime the
> application would need to be built for that.
>
>
]
Sent: 30 March 2010 18:06
To: Renato Oliveira
Cc: Tino Schwarze; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Migrate postgres to newer hardware
Renato Oliveira wrote:
> Are there any commercial solutions out there for migrating large DBs?
>
I'm not aware of any. The main way to a
--Original Message-
From: Dai, Tino [mailto:t...@loc.gov]
Sent: 31 March 2010 03:08
To: Greg Smith; Renato Oliveira
Cc: pgsql-admin@postgresql.org; Tino Schwarze
Subject: RE: [ADMIN] Migrate postgres to newer hardware
Hi Everybody,
I'm not a dba. I'm a sysadmin by training.
n
find.
-Tino
From: pgsql-admin-ow...@postgresql.org [pgsql-admin-ow...@postgresql.org] On
Behalf Of Greg Smith [g...@2ndquadrant.com]
Sent: Tuesday, March 30, 2010 1:05 PM
To: Dai, Tino; Renato Oliveira
Cc: pgsql-admin@postgresql.org; Tino Schwarze
Subject: Re: [ADMIN] Migrate po
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> What would be the easiest and fastest way to
> migrate Postgres 8.2.24 32 BIT to a new server 64 Bit.
...
> 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 v
Renato Oliveira wrote:
Are there any commercial solutions out there for migrating large DBs?
I'm not aware of any. The main way to address this problem by throwing
money at it is to hire someone extremely familiar with PostgreSQL
replication technology and figure out how to customize one
On Tue, 2010-03-30 at 16:38 +0200, Tino Schwarze wrote:
> 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 sig
> -Original Message-
> From: Renato Oliveira
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] 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 Postgre
take less
time that export.
Anyway, if you cannot leave database down for a day, I think slony will
be your best bet, although it's not exempt of problems. :)
-Original Message-
From: Renato Oliveira
To: Iñigo Martinez Lasala
Subject: RE: [ADMIN] Migrate postgres to newer hardware
Date:
On Tue, Mar 30, 2010 at 8:51 AM, Renato Oliveira
wrote:
> If I use postgres 32 bit will it benefit from the extra memory on the system?
Indirectly, yes. No individual PG process will be able to address
more than 4 gbytes of memory. Assuming you have a 64-bit OS living
underneath, however, that
Renato Oliveira writes:
> If I use postgres 32 bit will it benefit from the extra memory on the system?
Yes, although perhaps not as much as you'd get with a 64-bit build.
You still get the ability to have more than 4GB worth of kernel-managed
disk cache, and in many situations that's all the val
2010/3/30 Renato Oliveira :
> If I use postgres 32 bit will it benefit from the extra memory on the system?
>
> I don't think it will.
>
> Thank you very much
>
> Renato
>
Depending on the system, with a 32Bit OS you can only address 2 or 3
GB of continuous memory. 64Bit OS's have not this limitat
Matt
-Original Message-
From: pgsql-admin-ow...@postgresql.org
[mailto:pgsql-admin-ow...@postgresql.org] On Behalf Of Tino Schwarze
Sent: Tuesday, March 30, 2010 9:39 AM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Migrate postgres to newer hardware
Hi Renato,
dump/restore is
: Re: [ADMIN] 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
t: 30 March 2010 15:39
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] 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
2 and everything is
> running smooth.
>
> -Original Message-
> From: Renato Oliveira
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] Migrate postgres to newer hardware
> Date: Tue, 30 Mar 2010 12:18:36 +0100
>
> Dear All,
>
>
>
> What would
office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
-Original Message-
From: Brad Nicholson [mailto:bnich...@ca.afilias.info]
Sent: 30 March 2010 15:38
To: Iñigo Martinez Lasala
Cc: Renato Oliveira; pgsql-admin
Subject: Re: [ADMIN] Migrate postgres to newer hardware
On Tue, 2010
On Tue, 2010-03-30 at 16:29 +0200, Iñigo Martinez Lasala wrote:
> Hi Renato.
>
> I would follow the ancient method: perform a pg_dump / pg_restore
This is the easiest approach. The problem is that a lot of people have
contractual SLA's that do not allow them to take their systems down long
enoug
aving also to upgrade to new tsearch2 and everything is
running smooth.
-Original Message-
From: Renato Oliveira
To: pgsql-admin@postgresql.org
Subject: [ADMIN] Migrate postgres to newer hardware
Date: Tue, 30 Mar 2010 12:18:36 +0100
Dear All,
What would be the easiest and fast
Guz; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Migrate postgres to newer hardware
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.
>
>
>
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 G
igrate postgres to newer hardware
2010/3/30 Renato Oliveira
mailto:renato.olive...@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.
2010/3/30 Renato Oliveira
>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 PI
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
34 matches
Mail list logo
