pg_restore prend beaucoup plus de temps que pg_dump

Je sauvegarde régulièrement et restaure plus tard une petite base de données PostgreSQL, qui est utilisée pour les tests. Ses données sont mises à jour régulièrement à la suite de tests, puis un nouveau vidage doit être effectué, et les vidages sont régulièrement utilisés pour recréer la base de données dans un état bien défini.

J'ai remarqué que le vidage (utilisation pg_dump -Fc database) ne prend que quelques secondes, mais la restauration ( pg_restore -d database) prend environ une minute. Cela semble bizarre. Je m'attendais à ce que les deux prennent à peu près le même temps (en supposant que les deux tâches sont liées aux E / S).

Y a-t-il un problème avec la restauration? Pourrais-je peut-être accélérer les choses? Ou est-il normal que la restauration prenne beaucoup plus de temps que le vidage? (Et si oui, alors pourquoi?)

Le fichier de vidage a généralement environ 3-4 Mio; le SGBD est PostgreSQL V8.4, fonctionnant sur un Pentium4 3GHz avec 1 Go de RAM sous Ubuntu Linux.

performance postgresql database-backup

— sleske
source

Réponses:

Le contenu d'un index ne fait pas partie de la sauvegarde, seulement la définition de l'index. Et cela ne prendra que quelques octets. Lorsque l'index est créé pendant la restauration et que toutes les données sont indexées, il sera beaucoup plus volumineux. Cela prendra du temps, mais cela dépend de votre situation combien de temps.

pg_restore a une option pour la restauration simultanée (à partir de la version 8.4), utilisez--jobs=number-of-jobs

— Frank Heikens
source

Intéressant, merci. Existe-t-il un moyen de vider l'index également, pour accélérer la restauration (au prix d'un fichier de vidage plus volumineux)?

— sleske

Non, le contenu de l'index ne peut pas faire partie de la sauvegarde. Pour une très petite base de données comme la vôtre (3-4 Mio), cela ne devrait pas être un problème de toute façon.

— Frank Heikens

Informations supplémentaires: pg_dump n'a pas accès au contenu d'un index. pg_dump utilise des instructions SELECT pour obtenir tout le contenu des tables et le contenu des tables système pour créer la sauvegarde. C'est "juste" un wrapper autour de certaines instructions SELECT et de certaines fonctions pour écrire les résultats sur le disque.

— Frank Heikens

@Frank: Merci. Ne connaissait pas l'implémentation de pg_dump. Dans notre cas, accélérer la restauration serait utile, car elle doit être exécutée à plusieurs reprises dans le cadre de tests automatisés, donc la réduire de 1 minute à 10 secondes serait utile. Mais apparemment, ce n'est pas possible. Je vais devoir trouver une solution différente ...

— sleske

@sleske, vous pourriez essayer avec l' approche de sauvegarde du système de fichiers . Cela devrait préserver les index et, en outre, probablement s'exécuter un peu plus vite pour la sauvegarde et la restauration

— Stefano

Pour une restauration, la base de données doit faire beaucoup de travail supplémentaire:

Certaines choses me viennent immédiatement à l'esprit:

Écrire est plus lent que lire
L'analyse de l'entrée prend du temps
Mise à jour des index et autres structures internes
Maintenir l'intégrité référentielle

Je ne sais pas si cela correspond à cette différence de temps, cependant.

— Sven
source