Hey Daniel, copying is fine. But you *will* need to restart couchdb if you pull the rug out from under its feet, aka change the file it may have cached data from.
If you can I strongly recommend using something like zfs or btrfs to make switching back to snapshots super easy. It's a blast! A+ Dave On 18 March 2014 12:13, Daniel Gonzalez <[email protected]> wrote: > Hi, > > I have two local couchdbs instances (running on different ports): one > master-instance and one testing-instance. Master is a local-copy of my real > data in the production servers, arriving via replication, but otherwise I > do not use it for anything: it is just a local copy that I am using as > check-point to recreate the local testing databases. > > Both have the same data, but I am doing testing on the testing-instance, > so sometimes I want to "reset" the testing-instance to the state of the > master-instance (which, as said, is a copy of the real production data) > > BTW, I am using this intermediate master instance because this way I have > always a copy of the production data available; this means that even when I > have no network available, I can reset the testing instance: only the most > recent changes to the production data which could not be replicated because > of the non-existing network connection are missing, and I can live with > that. > > I can recreate the testing instance by replicating master -> testing, but > since some of the databases are very big, view recalculation takes hours. I > am trying to implement a faster method by doing: > > 1. Stop master and testing instances > 2. Copy all databases / design documents / views from master to instance > 3. Restart master and instance > > My question is simply: what are the consequences of recreating databases by > doing a filesystem copy? Is this going to be accepted by couchdb, or is it > mandatory to enter the data via replication / REST? > > Thanks and regards, > Daniel Gonzalez
