So, CouchDB will open a file descriptor to the .couch file when you first perform an operation to the database, and it will be kept open until either couchdb is stopped or it crashes or you have made requests against many other databases (there's a configurable LRU to keep file handles manageable). If you copied a .couch file over the top of the the existing .couch file, CouchDB will _not_ notice and will continue reading/writing the original file.
Copying .couch files into running servers is not the way to keep them in sync, you should use replication if that is your need. B. > On 8 Sep 2016, at 06:22, [email protected] wrote: > > Robert, > > I think I missed the point of your message in the first place. What you said > is that we might see the problems we see because wo copied the .couch file > onto the Windows machine while the server was running.... > > In fact, we never stop couch on our dev machines. So this might be part of > our problem. But these are not servers so we can be very sure couch was not > serving documents or such at the time of the file copy. > > I must admit I am not aware that there is something like a "stop" command for > couch. But I am interested in learning more about this, because if this is > our only problem, we'd have little to change in our current processes... > > Joachim > > Am 07.09.16 um 22:02 schrieb Robert Samuel Newson: >> .couch files should be portable between operating systems, but you shouldn't >> be writing .couch files into a couchdb server while it's running. It's >> completely file to copy .couch files _from_ a running server, though. >> >> Obviously replication is the better answer in general since all servers can >> be online at all times. >> >> B. >> >> >>> On 7 Sep 2016, at 16:05, [email protected] wrote: >>> >>> Stefan, >>> >>> Am 07.09.16 um 14:37 schrieb Stefan Klein: >>>> Hi, >>>> >>>> Replication is one-way. >>> Great, good to know. >>> >>>> Either target pulls from source or source pushes to target. >>>> >>>> You don't want to, but if you would like to keep 2 databases in sync you >>>> have to setup 2 replications db1 pulls from db2 and db2 pulls from db1, db2 >>>> pushes to db1 and db1 pushes to db2 .. and so on. >>> Okay, not relevant in this case, but good to know. I like this, because >>> there is no "magic" in it and this makes things simple. >>> >>>> Since you want the production DB to hide behind a firewall i guess best >>>> solution for you is to setup the production DB pushing to the development >>>> machine and setup the firewall to not allow any new (packets with set syn >>>> flag) from development network to production network / couchdb. >>> Well, in our case there is no known development network, so the firewall >>> setup is probably not possible as you say, but the idea of pushing down >>> from the production machine sounds interesting. I wouldn't have thought of >>> that. I thought pull from outside is the most logical model ;-) >>> >>> I will do some research in this direction. So far, I like what I read: we >>> could use this scenario for only pushing down changed documents since last >>> sync, which makes absolute sense in our scenario because it saves a lot of >>> bandwidth and we need to do this with laptops anywhere on the planet ;-) >>> >>>> (I didn't double check this actually works or if the target would also >>>> initiate requests to the source in this schema) >>> I will just bind my shoes and walk off into that direction and see how far >>> I get. Maybe next time I will already be able to ask qualified questions ;-) >>> >>> Thanks for your ideas >>> >>> >>> Joachim >> >
