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

Tout d'abord, je suis un développeur et non un administrateur de base de données ou un administrateur système; Soyez gentil s'il vous plait :)

Je travaille sur un workflow d’application dans lequel une seule action entraîne des modifications 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. Au total, environ 12 tables (sur environ 100) ) sont touchés par cette action. En raison de la complexité de cette tâche, il est très difficile pour moi 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 flux de travail, mais lorsque je suis sur le point de valider mes modifications, je dois tester la réalité.

J'ai une copie locale de la base de données de production avec laquelle travailler. Dans mon cas, le dumping et la restauration entre les tests sont plus rapides 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 assuré d'être le seul utilisateur du système et j'ai un accès root. Le vidage de la base de données fait ~ 100 Mo une fois taré et gzipé. La version de PostgreSQL est 8.3.

Merci d'avance pour toutes idées utiles.

Vous pouvez utiliser des instantanés au niveau du système de fichiers, mais cela est souvent assez fastidieux, 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 celle-ci pour votre exécution de test, à l'aide de la CREATE DATABASE ... TEMPLATEfonctionnalité. Après le test, vous jetez cette base de données. Ensuite, votre contrainte de vitesse est essentiellement le temps nécessaire pour cp -Raccéder au répertoire de la base de données. C'est à peu près aussi vite que vous obtiendrez sans la magie instantanée des instantanés du système de fichiers.

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

Stellar vous permet de restaurer rapidement la base de données lorsque vous écrivez par exemple des migrations de base de données, changez de branche ou manipulez SQL. PostgreSQL et MySQL (partiellement) sont supportés.

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 avez vraiment beaucoup de données dans la base de données ou le système d'exploitation ou très peu). peu de mémoire allouée à la machine virtuelle) gratuitement.

Dans la plupart des cas, il serait préférable d'installer un Linux léger (qu'un serveur Windows) pour exécuter la machine virtuelle sur laquelle la base de données est hébergée, sachant 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 risque de ne pas vous convenir).

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

Trouvé cette question en essayant de faire la même chose et fini par utiliser git sur le répertoire de données postgresql. Ignorer les modifications est aussi simple que:

git reset --hard

Une autre option qui pourrait être expérimentée consisterait à enregistrer une copie du répertoire de données postgresql, puis à réécrire simplement 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, cependant, ce serait donc une bonne idée de faire quelques tests, d'abord.

Même si je dois dire que la Stellaret git reset --hardest une solution intéressante, je vais avoir un problème avec des bases de données et des tests plus volumineux, et j’utilise les Virtualboxsolutions, etc. utilisez des solutions de métal nu, etc.

Je dois donc mentionner en ZFStant que système de fichiers à prendre en compte ces problèmes à 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 le 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 $SNAPSHOTdémarrez le postgresql, puis effectuez un retour en arrière, arrêtez le postgresql etzfs rollback $SNAPSHOT

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