Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Très bonne nouvelle : grâce aux nouveaux paramètres que vous m'avez conseillés, la restauration a duré 2 jours et 9 heures !
Je suis ravi, merci beaucoup à vous, c'est un beau cadeau de fin d'année 
.
J'ai modifié également le fichier système /etc/sysctl.conf pour y ajouter les lignes ci-dessous :
kernel.shmall = 2097152
kernel.shmmax = 4419829760
kernel.shmmni = 4096
Sinon j'avais une erreur pour le paramètre "shared memory".
Merci Rjuju pour votre complément au sujet des idées d'amélioration, mes réponses à vos questions :
- pour l'image disque du serveur : snapshot au niveau système de fichier,
- pour la configuration du RAID : c'est du RAID 1 (les 2 disques 146Go et 2To sont doublés).
Bien cordialement.
Bonjour à tous.
Tout d'abord, un très grand merci pour vos conseils.
Ensuite, effectivement, rien d'autre ne tourne sur cette machine et les données sont bien sur le 2ème disque de 2TO en RAID.
Je vais donc faire une nouvelle restauration avec les paramètres conseillés :
work_mem = 120MB
maintenance_work_mem = 1GB
checkpoint_segments = 50
shared buffers = 2GB
full_page_writes = on
wal_buffers = 32MB
auto_vacuum = off
max_connections = 50
checkpoint_timeout = 30min
checkpoint_completion_target = 0.9
checkpoint_warning désactivé
Nb jobs : 4
Enfin, pour améliorer la gestion des données, on a émis plusieurs idées et questions :
- découper la base de 620GB en plusieurs bases, leur taille sera donc plus réduite, est-ce qu'il vaut mieux plusieurs petites bases à restaurer qu'une seule base très volumineuse ?
- étudier la restauration PITR comme vous le suggérez très judicieusement, en même temps je pense qu'il faut faire une première restauration de toutes les données et ensuite il est possible de restaurer les paquets correspondant au différentiel (corrigez-moi si je me trompe),
- changer le disque dur pour un plus rapide de 10 000 tpm ou (si le budget le permet) un SSD,
- passer à la version 9.3 de postgresql pour faire la parallélisation en sauvegarde et en restauration en format répertoire.
- faire une image disque du serveur.
RDV dans plusieurs jours pour le résultat de la restauration .
Bien cordialement.
Bonjour,
Je souhaiterais avoir un avis pour savoir si le temps de restauration de mes données peut être optimisé.
Après avoir lu des messages sur plusieurs forums, j'ai fait plusieurs tests en changeant des paramètres dans postgresql.conf et en utilisant l'option de parallélisation de pg_restore. J'ai bien rechargé la config de postgresql en faisant pg_ctl reload.
J'ai augmenté les paramètres concernant la mémoire, la valeur de checkpoint_segments pour réduire le nombre de vérifications, désactivé l'auto-vacuum... Je ne sais pas quelles sont les valeurs critiques à ne pas dépasser, sauf pour la mémoire car limitée à 8 Go dans ma config.
Le meilleur temps que j'obtiens est 13 jours pour 620 Go de données regroupées dans une base.
Il y a sûrement quelque chose qui m'échappe car je suis novice sur ce sujet.
Merci d'avance pour vos conseils et suggestions.
Ci-dessous la config pour le meilleur temps :
PostgreSQL : 9.2
Système : Linux
Distribution: OpenSUSE 12.2 (Mantis) (x86_64)
Disques durs :
-1er : 146Go SAS 6Gbit/s 10000tr/min
-2ème : 2To Near Line SAS 6Gbit/s 7200tr/min
Mémoire : 8 Go
CPU : Intel® Xeon® CPU E5503 2.00 GHz cache size 4096 KB 2 processeurs à 2 cœurs chacun
Dans postgresql.conf:
work_mem = 60MB
maintenance_work_mem = 512MB
checkpoint_segments = 20
shared buffers = 512MB
full_page_writes = off
wal_buffers désactivé
auto_vacuum = off
max_connections = 100
checkpoint_timeout désactivé
checkpoint_completion_target désactivé
checkpoint_warning désactivé
Nb jobs : 2
Extrait du script de sauvegarde :
pg_dump -v -Fc -f masauvegarde.bak mabase
Extrait du script de restauration :
pg_restore -j 2 -d mabase -Fc masauvegarde.bak
Pages : 1
