Précédent   Forum des professionnels en informatique > Bases de données > PostgreSQL
PostgreSQL Forum PostgreSQL. Avant de poster -> F.A.Q PostGreSQL Tutoriels PostGreSQL
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 25/01/2011, 17h12   #1
Membre actif
 
Avatar de Empty_body
 
Inscription : mai 2004
Messages : 679
Détails du profil
Informations forums :
Inscription : mai 2004
Messages : 679
Points : 186
Points : 186
Par défaut Accélérer la restauration d'un dump.

Bonjour à tous,

J'utilise actuellement PostgreSQL 8.2 sur quelques serveurs centos 32bits, l'un de mes clients demande à changer son infrastructure pour passer sur un environnement 32 bits. Il semble que copier le répertoire "data" de postgres d'un serveur 32 bits vers un serveur 64 bits ne fonctionne pas. (je passe pourtant par le mode backup) J'ai lu qu'il fallait passer obligatoirement par un dump et une restauration (pgdump//pgrestore) lorsque l'on effectue ce type de changement d'environnement. Existe-t-il un mode de postgreSQL (paramètres du postgresql.conf?) qui permette d'accélérer la restauration de dumps? Existe-t-il un module qui peut être installé en complément de PostgreSQL?
__________________
Pourquoi vouloir ré-inventer la roue...
...Surtout si c'est pour la faire carrée...
Empty_body est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 26/01/2011, 16h44   #2
Membre Expert
 
Avatar de scheu
 
Inscription : juin 2007
Messages : 1 497
Détails du profil
Informations forums :
Inscription : juin 2007
Messages : 1 497
Points : 1 483
Points : 1 483
Vérifier que ton mode de sauvegarde se fait bien avec les paramètres par défaut, c'est-à-dire les données exportées avec COPY et non INSERT (beaucoup plus rapide à la restauration)

Eventuellement augmenter le paramètre maintenance_work_mem dans postgresql.conf, qui permet d'avoir plus de mémoire disponible quand il va recréer les indexes

Peut-être aussi désactiver l'archivage des WALs si tu l'as activé, pour ne le réactiver qu'après la restauration et faire une sauvegarde juste derrière

Voir aussi sur quels objets la restauration est longue :
- si c'est sur des tables, c'est très lié à la vitesse des disques
- si c'est sur des indexes, disques + CPU
- si c'est sur des recréations de foreign key, j'ai déjà vu des cas où ça pouvait être très long lorsqu'il n'y avait pas d'indexes sur les colonnes de la table référencée
__________________
La théorie, c'est quand on sait tout mais que rien ne fonctionne.
La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/
scheu est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 26/01/2011, 16h46   #3
Modérateur
 
Inscription : octobre 2008
Messages : 1 505
Détails du profil
Informations personnelles :
Localisation : France, Paris (Île de France)

Informations forums :
Inscription : octobre 2008
Messages : 1 505
Points : 2 034
Points : 2 034
pg_restore a un paramètre -j de parallélisation à partir de la version 8.4
Tu peux essayer d'utiliser un pg_restore 8.4 pour restaurer vers un serveur 8.2, en principe ça peut fonctionner.
estofilo est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 03h08.


 
 
 
 
Partenaires

Hébergement Web