Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-fr-generale by date

Next:From: felDate: 2011-06-06 09:47:06
Subject: Re: Conseil sur Migration
Previous:From: Bernard SchoenackerDate: 2011-06-03 11:29:48
Subject: Re: Conseil sur Migration

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group