couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds (JIRA)" <j...@apache.org>
Subject [jira] Updated: (COUCHDB-704) Replication can lose checkpoints
Date Fri, 20 Aug 2010 07:33:16 GMT

     [ https://issues.apache.org/jira/browse/COUCHDB-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Randall Leeds updated COUCHDB-704:
----------------------------------

    Attachment: keep_session_id.patch

Here's my new, preferred solution. It keeps the session_id for a replication in the replicator's
state. This way, a single replication session still shows up as only one entry in the history
log but if only one log gets written during some checkpoint pass the compare_rep_history will
still find an older checkpoint if it exists.

It's not even a problem if the recorded_seq doesn't match. Either one will work since the
checkpoint isn't written until a full commit has been performed on both source and target
dbs. So as long as the session id matches, starting from whichever recorded_seq should be
fine. The important thing is that we find a session_id in the log that matches so we don't
lose lots of checkpoint progress.

> 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