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


52

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 dites que vous avez le vidage de la base de données, n'est-ce pas suffisant? Testez votre système. En cas de problème, utilisez la sauvegarde pour rétablir l'état initial de la base de données et poursuivre le développement.
DrColossos

1
Restaurez-vous uniquement les tables qui ont changé?
Jack Douglas

1
@ Jack Douglas: Je restaure l'intégralité de la base de données à partir de la décharge. Les tables en question représentent environ les deux tiers des données et je devrais tout de même me soucier de l'ordre de restauration correct et des restrictions de clé étrangère.
Zilk

1
@DrColossus: oui, les dumps suffisent à restaurer l'état précédent, mais leur création et leur application sont très lentes.
Zilk

Réponses:


35

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.


C'est une très bonne idée. Je n'avais pas du tout pensé aux modèles de base de données. Je vous remercie!
Zilk

1
C'est une excellente solution, 5 fois plus rapide que drop-restore, mais présente un inconvénient: vous devez abandonner les connexions en cours avant de procéder, sinon le processus échouera.
sorin

Mise à jour: cela ne fonctionnera pas en production car la base de données source aura des connexions. Nous avons besoin d'une autre solution.
Sorin

11

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.



liquibase ne le supporte pas comme Stellar, où vous pouvez travailler avec la base de données (par exemple dans des tests unitaires) et devoir revenir à un état ou à une heure balisés précédemment.
Andreas Dietrich

Stellar semble être une bonne idée, mais ne fonctionne pas pour moi
Orlando

5

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).


Ah, tant pis, je n'ai pas vu votre commentaire qui mentionne que vous connaissez déjà virtualbox.
Wildpeaks

3

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


Oui, cela m'est venu à l'esprit. Malheureusement, les instantanés de système de fichiers ne sont pas pris en charge par le système de fichiers que j'utilise actuellement (ext3). Une autre option serait de configurer une machine virtuelle, telle que Virtualbox, pour les tests.
Zilk

2

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

6
Ceci n'est d'aucune utilité pour les bases de données volumineuses. De plus, pourquoi torturer Git avec des fichiers binaires de taille variable?
RolandoMySQLDBA

0

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.


0

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;)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.