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


Reply via email to