Thanks Dave, Yes, I understand that I need to restart it. Actually, I assume that both source and destination must be stopped while copying: - source to avoid data changes while copying, which can lead to inconsistent data being copied - destination to avoid that two processes (cp and couchdb) are stepping on each writing on the same files.
But that is fine with me. Using zfs / btrfs is overkill for my use case, because I have no experience with that and I would anyway need to re-install my system, or move couchdb databases to another partition, which I do not have. Nice idea to keep in mind for the future though. BR, Daniel On Tue, Mar 18, 2014 at 12:17 PM, Dave Cottlehuber <[email protected]>wrote: > 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 >
