Check to see if instance_start_time is changing. It's included in the output of GET /dbname, so it's an easy find. Make a note of it for both ends of your replication before your test and then after you get the 'out of sync' message. Once you've identified which end is resetting, see if the couch.log shows the database crashing or being closed by the LRU.
B. On 15 July 2013 18:29, Will Perry <[email protected]> wrote: > Thanks for the speedy reply. > > When running the scenario, each node only has one user db (plus, of course > _replicator and _users) - there's a repl. Relationship setup for the existing > db, but I can't see how I'd get anywhere near 100 open dbs with this setup. > > Might it help to 'warm up' these new dbs by running a few queries against > them before trying to replicate? > > Cheers, > > Will > > -----Original Message----- > From: Robert Newson [mailto:[email protected]] > Sent: Monday, July 15, 2013 10:21 AM > To: [email protected] > Subject: Re: Understanding 'Source database out of sync' error > > The replicator checks the instance_start_time of both servers and restarts > the replication if they change. This is essential to ensure we replicate > everything. The reason it recommends increasing max_dbs_open is that > instance_start_time only changes if the database has previously closed, and > this is commonly because the LRU has done so. > > Does it sound plausible that you have more actively replicating databases at > either end than your current max_dbs_open value? I believe the default value > is 100. > > B. > > > On 15 July 2013 18:09, Will Perry <[email protected]> wrote: >> Hi Folks, >> >> I'm seeing the following error pop up when attempting to write a new >> document into the _replicator database referencing a newly created database: >> >> checkpoint_commit_failure,<<"Source database out of sync. Try to >> increase max_dbs_open at the source's server.">> >> >> The scenario I'm running is: >> >> 1. On 2 couch nodes A and B >> >> 2. Create a new database named 'Foo' on A, then on B >> >> 3. Create a replication relationship on A to pull changes from B >> >> 4. Create a replication relationship on B to pull changes from A >> >> This is failing at step 3 with a 400 (bad request) and Couch's logs are >> showing me the error above. Incidentally, the same code used to work (on >> 1.2) - is there a known issue or workaround? >> >> Cheers, >> >> Will > > >
