Question

I have a production server running an app that uses CouchDB as its main database. I’d like to set up a staging server that has a CouchDB instance that I can always sync back up to the production instance and get a clean copy.

A naive solution would be simply to have the staging server continuously replicate the production server’s database, and just use that. The problem of course is that in the course of testing on the staging server, I may do things that modify the database.

Functionally correct would be for me to delete the database every time and re-replicate from production; but obviously this would take a reeeeeeaaally long time if I had to start from scratch every time.

I’m looking for a solution something like: 1) Keep a pristine copy of the production db on the staging server, that is constantly reindexing its views 2) copy all the db files including the indexes to a db named something else 3) use that and blow it away when done.

Has anyone ever tried something like this and Does copying db files and renaming them even work smoothly? If so, what files do and don’t need to be copied?

Answer 1

Your approach is what I would recommend. Copying DB and index files to a new name works as expected.

Check /_config/couchdb for your values of database_dir and view_index_dir and then

cd $database_dir
cp live_replica.couch local_copy_to_mess_with.couch

cd $view_index_dir # most likely the same dir
cp -r .live_replica_design .local_copy_to_mess_with_design

Make sure to run these commands as the owner of all the other files in these directories, e.g. couchbase, or else couchdb won’t have the permissions to use the files you create. You can check correct owners and groups with ls -alR.