incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: What causes compaction to retry?
Date Fri, 25 Mar 2011 20:25:07 GMT
On Fri, Mar 25, 2011 at 13:20, Wayne Conrad <wayne@databill.com> wrote:
> I've got a largish database that is being both compacted and synchronized
> concurrently.
>
> $ curl --silent topaz:5984/_active_tasks | prettify_json.rb
> [
>  {
>    "pid": "<0.313.0>",
>    "type": "Replication",
>    "task": "`874dbdaf26454065f33007eb42c8320a+create_target`:
> `http://sodium:5984/incoming/` -> `incoming`",
>    "status": "Processed source seq 477428"
>  },
>  {
>    "pid": "<0.24865.58>",
>    "type": "Database Compaction",
>    "task": "incoming retry",
>    "status": "Copied 106794 of 159518 changes (66%)"
>  }
> ]
>
> At first the task was just "incoming", but when it got to 100%, it started
> over again with the task now being "incoming retry."  It's gotten to the end
> a few times now, each time starting over as a "retry" task.  What causes
> that?
>

When compacting, Couch traverses a snapshot of the database and copies
the current revisions out to a new, compacted database file.
When it reaches the end, it needs to incorporate any new revisions
that happened during the first pass.
Each successive retry should be much faster than the last.
In theory, if the database is busy enough, compaction might never
finish. In practice, I don't think anyone has ever seen this occur.

R

Mime
View raw message