È possibile creare / ripristinare rapidamente gli snapshot del database con PostgreSQL?

Prima di tutto, sono uno sviluppatore, non un DBA o un amministratore di sistema; per piacere sii gentile :)

Sto lavorando a un flusso di lavoro dell'applicazione in cui un'azione di un singolo utente attiverà modifiche complesse nel database: la creazione di centinaia di record in alcune tabelle, l'aggiornamento di centinaia di record in altri, ecc. Tutto sommato, circa 12 tabelle (su ~ 100 ) sono toccati da questa azione. A causa della complessità, è molto difficile per me ripristinare manualmente tutte le modifiche prima di poter eseguire un altro test. Durante la maggior parte del mio tempo di sviluppo, posso semplicemente inserire un'istruzione "ROLLBACK" verso la fine del flusso di lavoro, ma quando mi avvicino al commit delle modifiche, devo testare la realtà.

Ho una copia locale del database di produzione con cui lavorare. Nel mio caso, scaricare e ripristinare tra i test è più veloce della scrittura di uno script per annullare tutte le modifiche. È più veloce, ma mi sta ancora rallentando molto (il ripristino richiede circa 20 minuti sul mio vecchio laptop). Esiste un modo per salvare un'istantanea dello stato corrente del database e ripristinarlo rapidamente?

Sono sicuro di essere l'unico utente sul sistema e ho accesso come root. Il dump del database è ~ 100 MB quando viene tarato e decompresso. La versione PostgreSQL è 8.3.

Grazie in anticipo per eventuali idee utili.

È possibile utilizzare snapshot a livello di file system, ma spesso è piuttosto ingombrante, richiede file system speciali e non è sempre disponibile, soprattutto su laptop obsoleti. ;-)

Che ne dici di creare il tuo stato di base come database e quindi creare un nuovo database da esso per l'esecuzione del test, utilizzando la CREATE DATABASE ... TEMPLATEfunzionalità. Dopo il test, butti via quel database. Quindi il tuo limite di velocità è essenzialmente solo il tempo alla cp -Rdirectory del database. È più veloce di quanto otterrai senza la magia dell'istantanea del file system.

Usa Stellar , è come git per i database:

Stellar ti consente di ripristinare rapidamente il database quando, ad esempio, stai scrivendo migrazioni di database, cambiando filiali o inviando messaggi con SQL. PostgreSQL e MySQL (parzialmente) sono supportati.

Se il tuo database viene eseguito in Virtualbox , puoi facilmente salvare le istantanee e ripristinare le istantanee dello stato del database e del sistema operativo stesso in pochi secondi (o 1-2 minuti se hai davvero molti dati nel database o nel sistema operativo o molto poca memoria allocata alla macchina virtuale) gratuitamente.

Nella tua / maggior parte dei casi, sarebbe meglio installare un Linux leggero (piuttosto che un server Windows) per eseguire la macchina virtuale in cui è ospitato il database dato che hai menzionato che hai poche risorse disponibili sul tuo laptop.

Sul sito di produzione, utilizzo i backup di snapshot di MediaTemple per ottenere lo stesso risultato (ma è 20 $ per slot di backup e specifico per quel servizio di web hosting, quindi potrebbe non adattarsi a te).

Probabilmente non è la risposta che speri, ma hai preso in considerazione un livello inferiore di snapshot, ad esempio LVM?

Ho trovato questa domanda quando ho provato a fare lo stesso e ho finito per usare git nella directory dei dati postgresql. Annullare le modifiche è semplice come:

git reset --hard

Un'altra opzione che potrebbe essere sperimentata sarebbe quella di salvare effettivamente una copia della directory dei dati postgresql, quindi riscrivere la directory esistente con la copia quando si desidera ripristinarla. Richiederà più spazio sul disco, ma sarà sicuramente più veloce del ripristino da un backup. Non sono sicuro se questo sarebbe più veloce del metodo template, quindi sarebbe una buona idea fare alcuni test, prima.

Anche se devo dire Stellarche git reset --hardè una soluzione interessante, avrò un problema con database e test più grandi, e utilizzo le Virtualboxsoluzioni ecc., Tuttavia, nei test più grandi, questi diventano un po 'più "problematici" quando si stanno usando soluzioni di metallo nudo ecc.

Quindi DEVO menzionare ZFScome filesystem da considerare in futuro per questi motivi per i seguenti motivi che anche @Peter Eisentraut ha menzionato:

1. Istantanee - specialmente quando si esegue la replica da Prod a QA / DR, è possibile utilizzare lo stesso "filesystem" per i test:

#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. per eseguire un test, appena prima del test esegui un arresto postgresql come sopra, zfs snapshot $SNAPSHOTavvia postgresql, quindi esegui il rollback, arresta postgresql ezfs rollback $SNAPSHOT

2. Compressione - Postgresql ottiene una tipica compressione 3: 1 nei miei database, quindi puoi fare molti altri test;)