web-dev-qa-db-fra.com

Est-il possible de créer / restaurer rapidement des instantanés de base de données avec PostgreSQL?

Tout d'abord, je suis développeur, pas DBA ni administrateur système; Soyez gentil s'il vous plait :)

Je travaille sur un flux de travail d'application où une seule action utilisateur déclenchera des changements complexes dans la base de données - création de centaines d'enregistrements dans certaines tables, mise à jour de centaines d'enregistrements dans d'autres, etc. En tout, environ 12 tables (sur ~ 100 ) sont touchés par cette action. En raison de la complexité, il m'est très difficile d'annuler manuellement toutes les modifications avant de pouvoir exécuter un autre test. Pendant la majeure partie de mon temps de développement, je peux simplement insérer une instruction "ROLLBACK" vers la fin du workflow, mais quand je suis sur le point de valider mes modifications, je dois tester la vraie chose.

J'ai une copie locale de la base de données de production avec laquelle travailler. Dans mon cas, le vidage et la restauration entre les tests est plus rapide que l'écriture d'un script pour annuler toutes les modifications. C'est plus rapide, mais cela me ralentit encore beaucoup (la restauration prend environ 20 minutes sur mon ordinateur portable vieillissant). Existe-t-il un moyen de sauvegarder un instantané de l'état actuel de la base de données, puis de le restaurer rapidement?

Je suis garanti d'être le seul utilisateur du système et j'ai un accès root. Le vidage de la base de données est de ~ 100 Mo lorsqu'il est taré et gzipé. La version de PostgreSQL est 8.3.

Merci d'avance pour toutes les idées utiles.

postgresqlrestoresnapshot
54
Zilk

Vous pouvez utiliser des instantanés au niveau du système de fichiers, mais cela est souvent assez lourd, nécessite des systèmes de fichiers spéciaux et n'est pas toujours disponible, en particulier sur les ordinateurs portables vieillissants. ;-)

Que diriez-vous de créer votre état de base en tant que base de données, puis de créer une nouvelle base de données à partir de celui-ci pour votre test, en utilisant le CREATE DATABASE ... TEMPLATE Fonctionnalité. Après le test, vous jetez cette base de données. Alors votre contrainte de vitesse n'est essentiellement que le temps de cp -R le répertoire de la base de données. C'est à peu près aussi rapide que vous obtiendrez sans la magie des instantanés du système de fichiers.

36
Peter Eisentraut

Utilisez Stellar , c'est comme git pour bases de données:

Stellar vous permet de restaurer rapidement la base de données lorsque vous êtes par exemple écrire des migrations de bases de données, changer de branche ou jouer avec SQL. PostgreSQL et MySQL (partiellement) sont pris en charge.

12
David Portabella

Si votre base de données s'exécute dans Virtualbox , vous pouvez facilement enregistrer des instantanés et restaurer des instantanés de l'état de la base de données et du système d'exploitation lui-même en quelques secondes (ou 1-2 minutes si vous en avez vraiment beaucoup de données dans la base de données ou l'OS ou très peu de mémoire allouée à la machine virtuelle) gratuitement.

Dans votre/la plupart des cas, il serait préférable d'installer un Linux léger (plutôt qu'un serveur Windows) pour exécuter la machine virtuelle où la base de données est hébergée, étant donné que vous avez peu de ressources disponibles sur votre ordinateur portable.

Sur le site de production, j'utilise les sauvegardes instantanées de MediaTemple pour obtenir le même résultat (mais c'est 20 $ par emplacement de sauvegarde et spécifique à ce service d'hébergement Web, ce qui peut ne pas vous convenir).

5
wildpeaks

Probablement pas la réponse que vous espérez, mais avez-vous envisagé un niveau inférieur d'instantané - LVM par exemple?

3
Jack says try topanswers.xyz

J'ai trouvé cette question en essayant de faire de même et j'ai fini par utiliser git sur le répertoire de données postgresql. Ignorer les modifications est aussi simple que:

git reset --hard
2
user92843

Bien que je doive dire les Stellar et git reset --hard est une solution intéressante, j'aurai un problème avec des bases de données et des tests plus volumineux, et j'utilise les solutions Virtualbox etc. vous utilisez des solutions de métal nu, etc.

Je DOIS donc mentionner ZFS comme un système de fichiers à considérer pour ceux-ci à l'avenir pour les raisons suivantes que @Peter Eisentraut a également mentionnées:

  1. Instantanés - en particulier lorsque vous effectuez une réplication de Prod vers QA/DR, vous pouvez utiliser ce même "système de fichiers" pour les tests:
#On a replication node, rather stop, snap, restore for a "consistent" backup ;)
su -l -c "/usr/bin/m2ee stop" acw_qa
pg_ctlcluster ${=QA} stop --force
zfs destroy -R $SNAPSHOT
pg_ctlcluster ${=REPLICATION} stop --force
zfs snapshot $SNAPSHOT
pg_ctlcluster ${=REPLICATION} start

zfs destroy $CLONE
zfs clone -o mountpoint=$CLONEDIR $SNAPSHOT $CLONE
rm $CLONEDIR/$CLUSTER/recovery.conf
pg_ctlcluster ${=QA} start
su -l -c "/usr/bin/m2ee start" acw_qa

  1. pour faire un test, juste avant le test, faites un arrêt postgresql comme ci-dessus, zfs snapshot $SNAPSHOT démarrer le postgresql, puis revenir en arrière, arrêter le postgresql et simplement zfs rollback $SNAPSHOT

  2. Compression - Postgresql obtient une compression 3: 1 typique dans mes bases de données, vous pouvez donc faire beaucoup de tests supplémentaires;)

0
Hvisage

Encore une autre option qui pourrait être expérimentée serait d'enregistrer réellement une copie du répertoire de données postgresql, puis de simplement réécrire le répertoire existant avec la copie lorsque vous souhaitez le restaurer. Cela nécessitera plus d'espace sur le disque, mais sera certainement plus rapide que la restauration à partir d'une sauvegarde. Je ne sais pas si cela serait plus rapide que la méthode du modèle, donc ce serait une bonne idée de faire quelques tests, d'abord.

0
Haroldo_OK