You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Wayne Conrad <wa...@databill.com> on 2011/03/25 21:20:56 UTC
What causes compaction to retry?
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?
Version: 1.2.0ac052866-git
Re: What causes compaction to retry?
Posted by Wayne Conrad <wa...@databill.com>.
On 03/25/11 13:25, Randall Leeds wrote:
> 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.
Randall, That made perfect sense. And indeed, it did finally run out of
things to compact. Thanks for the explanation.
Wayne Conrad
Re: What causes compaction to retry?
Posted by Randall Leeds <ra...@gmail.com>.
On Fri, Mar 25, 2011 at 13:20, Wayne Conrad <wa...@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