CouchDB works like this to have the least impact possible on clients,
the database remains online and fully functional to readers and
writers. Yes, its a design limitation that database compaction can't
complete when at capacity for write load, however I don't think its
unreasonable to schedule compactions during off-peak hours either. As
you point out, in a clustered environment the write load can switched
off for any node during compaction and brought back up to date with
replication once complete.
In the future, a single couchdb node can be changed to stop or fail
other updates if the write load is too heavy for it to complete in a
reasonable time.
On Jun 12, 2008, at 2:41 PM, Сергей Курцев wrote:
Hello, Damien.
Thanks for clearing that out. But according to your, I assume that
CouchDB may run on high-loaded servers in future. That means that the
only way to compact database on write-heavy systems is when using
several replicated CouchDB servers. We then should stop serving
requests
by the specific CouchDB while others continue with replicated copies
and
proceed with compact.
Not sure that this is the best way, but it shall work. But on the
single
running copy of CouchDB it still may be a problem, I guess.
