Re: Migrate postgres to newer hardware

Поиск
Список
Период
Сортировка
От Renato Oliveira
Тема Re: Migrate postgres to newer hardware
Дата
Msg-id 7965A9DCF12CC14984420BCC37B1608F25AB1AEF03@Elzar.grant.co.uk
обсуждение исходный текст
Ответ на Re: Migrate postgres to newer hardware  (Greg Smith <greg@2ndquadrant.com>)
Ответы Re: Migrate postgres to newer hardware  (Scott Marlowe <scott.marlowe@gmail.com>)
Список pgsql-admin
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.

Which one works best: bucardo, slony or Londiste?

I have researched Slony and Bucardo but have not heard of  Londiste before.

How many people are using all three of them and their review  have you heard anything about that?

Thank you again

Really Appreciate it

Renato



Renato Oliveira
Systems Administrator
e-mail: renato.oliveira@grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://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

-----Original Message-----


From: Greg Smith [mailto:greg@2ndquadrant.com]
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 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 of the
available approaches (Slony, Londiste, PITR, dump/restore) to match your
application.  For example, in some cases it's possible to record
database changes on the application side, replicate the database via one
of the fast online approaches like PITR, and then synchronize just the
changes made in the master while that was happening for a fast
switch-over to a new version.  It's not unheard for that to require
small application changes to support, to provide an easier way to log
the difference between the two.

If you can't take the additional load of Slony and have minimal
tolerance for downtime, you really need to come up with a long-term
approach to coping with that from an application architecture
perspective.  Unfortunately you're not going to find any quick fix for
that combination of requirements.

--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us




-----Original Message-----


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
toanother person or take copies. 

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system.
WhilstGrant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept
liabilityfor any damage which you sustain as a result of software viruses. You should therefore carry out your own
viruschecks before opening the attachment(s). 

OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our
http://www.grant.co.uk/Support/openxml.html


В списке pgsql-admin по дате отправления:

Предыдущее
От: Renato Oliveira
Дата:
Сообщение: Re: Migrate postgres to newer hardware
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: Migrate postgres to newer hardware