Correct, Andrea - the recommendation for 2.x is to always use FQDN in your replication documents.
Robert/Nick I seem to recall you mentioning this a while back...is there any plan to reintroduce correct behaviour for database names specified without an FQDN in replicator documents? -Joan ----- Original Message ----- > From: "Andrea Brancatelli" <[email protected]> > To: [email protected] > Sent: Monday, October 1, 2018 12:01:15 PM > Subject: Re: CouchDB 1.x to CouchDB 2.x > > Even on the new machine I just updated I'm having a lot of issues > with > Replication. > > The same _replicator docs that used to work on 1.7 don't work anymore > since the "local" database (I mean any source/target without an url) > doesn't seem to work with the very same scenario of the mail I sent a > few days ago. > > In the same way I could not get any kind of replication to work by > using > a FQDN in the Source or Target with a lot of complains about the > _session database. > > The only way to get it to work was using the machine IP in the source > and target url - this way the replication started but I'm receiving a > constant bunch of those errors in the log: > > [error] 2018-10-01T15:55:57.119670Z [email protected] <0.2287.13> > -------- couch_replicator_auth_session : Could not parse cookie from > response headers cookie_format_invalid > [error] 2018-10-01T15:56:05.683295Z [email protected] <0.2698.13> > -------- couch_replicator_auth_session : Could not parse cookie from > response headers cookie_format_invalid > [error] 2018-10-01T15:56:58.559221Z [email protected] <0.4899.13> > -------- couch_replicator_auth_session : Could not parse cookie from > response headers cookie_format_invalid > [error] 2018-10-01T15:57:08.167212Z [email protected] <0.5191.13> > -------- couch_replicator_auth_session : Could not parse cookie from > response headers cookie_format_invalid > [error] 2018-10-01T15:58:01.143074Z [email protected] <0.7405.13> > -------- couch_replicator_auth_session : Could not parse cookie from > response headers cookie_format_invalid > [error] 2018-10-01T15:58:11.539561Z [email protected] <0.7875.13> > -------- couch_replicator_auth_session : Could not parse cookie from > response headers cookie_format_invalid > > Given that this is happening with Couch talking directly to itself > I'm > pretty puzzled by the reason for this header cookie_format_invalid. > > Does anybody have any suggestion? > > --- > > Andrea Brancatelli > > On 2018-10-01 13:13, Andrea Brancatelli wrote: > > > Hello everybody. > > > > Today I upgraded the first CouchDB 1.7 to CouchDB 2.2 in production > > with > > the help of the marvellous couchup, by just coping the old .couch > > files > > in the new locations. > > > > Everything went smoothly apart from some points: > > > > * The Documentation doesn't mention the need for the -i switch when > > invoking couchup to migrate the _users and _replication databases. > > Maybe > > a note on this would be useful in scenarios when one is migrating > > an > > entire machine. > > * I had to manually reapply all the permission on the databases. > > Seems > > a quite obvious conseguence of the replication-process not > > replicating > > the security document. Yet I don't think that replicating a server > > into > > a totally open one makes a lot of sense. Did I miss something? > > > > Since I have to do a couple more Production servers with more > > complex > > permissions, do you have any brilliant suggestions on how to > > replicate > > permissions too? > > > > Quite frankly it sounds like an easy improvement to couchup as > > well, but > > personally I'm a bit python-adverse eheheh > > > > Thanks
