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.
>
>
>
|