couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Kocoloski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-704) Replication can lose checkpoints
Date Tue, 19 Oct 2010 13:41:27 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922557#action_12922557
] 

Adam Kocoloski commented on COUCHDB-704:
----------------------------------------

I think it's a _very_ good idea to reuse the session_id over the lifetime of a replication
job.  I've been burned by this in the past as well.  The only thing I take issue with in this
patch is the change to push new history entries for every checkpoint.  For a long-running
replication that means the checkpoint document will cover the last 5 minutes of the current
replication and nothing else.  I've occasionally found it useful to scan back through the
history to see the timestamps and statistics from older sessions for a particular replication,
and I don't think saving multiple entries for a given session_id adds anything to the durability
of that session.

What do you think about switching back to using #state.history for the OldHistory when saving
a checkpoint?

> Replication can lose checkpoints
> --------------------------------
>
>                 Key: COUCHDB-704
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-704
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 0.11.2, 1.0.1
>            Reporter: Randall Leeds
>            Priority: Minor
>         Attachments: keep_session_id.patch, save-all-rep-checkpoints.patch, whitespace.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> When saving replication checkpoints in the _local/<repid> document the new entry
is always pushed onto the _original_ "history" list property that existed at the start of
the replication. When any number of things causes the checkpoint to be written to only one
of the databases the head of the history list gets out of sync. Subsequent attempts to start
this replication must start from the latest common replication log entry in the _original_
history, as though this replication never occurred.
> A better idea is to push every checkpoint onto the history instead of replacing the head
on each save.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message