Re: Conseil sur Migration

From: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
To: Bernard Schoenacker <bernard(dot)schoenacker(at)free(dot)fr>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Conseil sur Migration
Date: 2011-06-03 11:41:55
Message-ID: BANLkTimNkiz0SEPdhEQPPw=uvYeDMWRgQw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Le 3 juin 2011 13:29, Bernard Schoenacker
<bernard(dot)schoenacker(at)free(dot)fr> a écrit :
> Le Fri, 03 Jun 2011 13:03:12 +0200,
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :
>
>> On Fri, 2011-06-03 at 12:40 +0200, fel wrote:
>> > J'aurais bien de conseils concernant une migration
>> >
>> > J'ai actuellement un serveur RHEL 5.2 32Bit et Potgres 8.3.
>> > Je souhaiterai migrer mes bases vers une version 9.0 de postgres et
>> > sur un serveur en 64bit.
>> >
>> > Quelle est la meilleure solution :
>> > - Dumper les data de 32 bit vers 64 et ensuite utiliser pg_upgrade
>> > pour passer en 9.0
>>
>> Aucun intérêt d'utiliser pg_upgrade si vous avez déjà à faire un
>> dump/restore.
>>
>> > - Passer en 9.0 avec pg_upgrade sur l'environnement 32 bit puis
>> > dumper les data vers le 64bit
>>
>> Aucun intérêt d'utiliser pg_upgrade si vous avez déjà à faire un
>> dump/restore (bis).
>>
>> De plus, je doute que vous puissiez utiliser pg_upgrade avec une
>> version 8.3, surtout une version communautaire, étant donné que le
>> integer-datetimes a changé entre la 8.3 et la 8.4.
>>
>> > - Dumper de 8.3 32bits et restaurer directement sur la version 9.0
>> > 64 bit.
>> >
>>
>> Sans aucun doute, c'est la méthode à choisir.
>
> bonjour,
>
>        j'ai omis d'indiquer également de faire attention au niveau de
>        l'encodage des données :
>
>        -a) origine     : iso_8859-1x || utf-8
>        -b) destination : utf-8

En venant d'un serveur 8.3 pas de soucis d'encoding à prévoir.
Pensez à utiliser le pg_dump de la version PostgreSQL du serveur de destination.

Si le volume est trop conséquent ou que le coupure doit etre la plus
courte possible, les alternatives viables sont d'utiliser slony par
exemple.

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message fel 2011-06-06 09:47:06 Re: Conseil sur Migration
Previous Message Bernard Schoenacker 2011-06-03 11:29:48 Re: Conseil sur Migration