Vous n'êtes pas identifié(e).
Bonjour,
Nous somme en phase d'étude de la mise en place PostgreSQL pour un future remplacement de nos bases de données Oracle.
Avez-vous une idée la durée de sauvegarde d'une base de données PostgreSQL pour une volumétrie d'environ 1 To ?
Merci pour votre réponse.
Hors ligne
Bonjour,
C'est pas évident de répondre comme ca. Ca dépend de la puissance du serveur employé, de la vitesse des disques, de la quantité de RAM, de se qui tourne au moment du dump, etc....
Si tu pouvais être plus précis sur la configuration employée par ton serveur qui héberge ta BDD Oracle, on pourrait éventuellement te répondre 
.
Hors ligne
Bonjour,
Cela dépend grandement du type de stockage ( SATA / SAN ) et du type de RAID employé (matériel ou logiciel).
Pour donner un exemple, avec des disques SATA 10k rpm montés en RAID 0 on peut obtenir des vitesses d'écritures séquentielles de 80Mo/s.
Dans une telle configuration, on peut s'attendre à une durée de sauvegarde entre 4 et 5 heures.
Là où PostgreSQL apporte une amélioration, c'est sur la restauration des données, notamment avec la version 8.4 qui est sortie hier, puisque la restauration peut désormais s'effectuer en parallèle. On manque encore de tests de performance concernant cette nouvelle fonctionnalité mais cela s'annonce très prometteur !
Par ailleurs, on trouve sur internet plusieurs témoignages concernant des bases de plusieurs To fonctionnant parfaitement sous PostgreSQL, notamment chez Météo France.
Plus d'informations :
http://people.planetpostgresql.org/andr … L-8.4.html
http://www.postgresql.fr/temoignages:meteo_france
http://georezo.net/forum/viewtopic.php?id=60566
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Malgré tout, pour de telles volumétries, il est habituellement préférable de faire une sauvegarde des fichiers de la base, plutôt qu'un import, même si effectivement avec le 8.4 on peut faire une restauration en parallèle (donc la procédure avec pg_start_backup). Sinon on a du mal à restaurer à la vitesse maximale des disques.
Marc.
Hors ligne
L'amélioration dont parle Damien concerne uniquement la 8.4. Pour les versions précédentes, la restauration est toujours beaucoup plus lente que la sauvegarde. Il me semble, comme Marc, que la sauvegarde des fichiers est préférable car plus rapide en sauvegarde et en restauration que n'importe quel autre système. Par contre, il faut soit arrêter PostgreSQL soit pouvoir faire une image du disque sans modification.
Guillaume.
Hors ligne
Il n'est pas nécessaire d'éteindre PostgreSQL pour faire cette image :
- Soit on passe par pg_start_backup, et on sauvegarde les journaux générés par la sauvegarde en fin de sauvegarde (apres le pg_stop_backup)
- Soit si on est sous un Unix avec un seul système de fichiers et un volume manager (ou plusieurs systèmes de fichiers mais ç'est plus compliqué), on fait un snapshot qu'on sauvegarde
Marc.
Hors ligne
Oui, c'est bien ce que je dis 
Faut quand même avoir confiance en son « volume manager ». Et ça gère assez peu fréquemment les tablespaces, cette histoire.
Guillaume.
Hors ligne
Avec un bon quiesce (ou freeze, si le FS le gère ...). Mais c'est vrai que c'est une des choses qui manquent sur ext3/4 pour le moment 
Donc privilégier le pg_start_backup, qui lui marche tout le temps.
Marc.
Hors ligne
pour ma part, sur de très grosses bases avec de volumineuxet nombreux index's, je préfère de très loin une sauvegarde logique que physique.
Quand à la restauration, on est clairement limité en version 8.4 par la vitesse d'accès disque lors de la création des index's (c'est d'ailleurs un des meilleurs benchmarks possibles pour les disques). Dans tous les cas, on va bien plus vite que la restauration d'un file system sans parler des problèmes causés par les tablespaces éparpillés sur plusieurs axes.
Cerise sur le gâteau, après restauration, on a une base très propre sans espace gaspillé :-)
Hors ligne
