Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Nathan Vander Wilt <nate-lists@calftrail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: "Target database out of sync. Try to increase max_dbs_open at the
 target's server."
Date: Mon, 3 Dec 2012 07:59:16 +0100
Message-Id: <BA607AE0-7DBA-403C-B20A-DAA22BA36833@calftrail.com>
To: user@couchdb.apache.org
Mime-Version: 1.0 (Apple Message framework v1283)

I keep seeing this error in my logs, from a replication between two =
database servers:

[Sat, 17 Nov 2012 18:16:21 GMT] [error] [<0.22441.709>] Error in =
replication `ec0cd75a82ec8f2089fae72e31b29aac+continuous+create_target` =
(triggered by document `replicate-to-staging`): =
{checkpoint_commit_failure,<<"Target database out of sync. Try to =
increase max_dbs_open at the target's server.">>}

Looking at the source code around that message, my understanding is that =
this will be logged when the timestamps found in the checkpoint document =
do not match what should have been written or=85something. (My Erlang-fu =
has only atrophied since excitedly reading the Armstrong book several =
years ago.)

The odd thing is, the target database in this case should have plenty of =
"max_dbs_open" headroom! I can't raise it further since the setting is =
not on the Iris Couch whitelist, but the target system has only 31 =
databases total (against the Iris Couch limit of 100). On the source =
side, there are 83 databases that could be open, but that's not what =
it's complaining about.

Replication seems to recover fine, but the dumps are clogging my logs =
and making it harder to track some other (real) continuous replication =
issues I'm trying to resolve. Any suggestions of what its real complaint =
is and how to resolve?

thanks,
-natevw=