You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2018/11/13 17:12:34 UTC
[GitHub] nickva opened a new pull request #1734: Stop replications on target
document write failures
nickva opened a new pull request #1734: Stop replications on target document write failures
URL: https://github.com/apache/couchdb/pull/1734
Previously when target document writes failed, because a VDU prevented the
write, or it exceed size limits on the target cluster, replication continued
and a `doc_write_failures` statistic counter was incremented. The counter was
visible in _active_tasks output for continuous replications and was visible in
the completion record written back to the replication documents.
That behavior might not be suitable in many cases. For instance, when migrating
data, if the counter is ignored by the user, combined with a successful
replication completion could lead to a perceived data loss. Until recently
00b28c265d97df675b725cd68897dc371cbd7168 this was even worse because on
replication scheduler would reset statistics counters on every job start. So if
a job restarted at least once, user might never find out that all their data
didn't copy from the source to the target.
Introduce a replicator config `stop_on_doc_write_failure = true | false` where
the replication crashes if a single document write fails. This will many write
failures visible to the and they would know exactly which document failed and
why.
Replications which crash because of doc write failures would retry periodically
just like any other crashes related to missing source or target connectivity,
for example. They do not fail permanently because users could adjust document
size limit on a target cluster or change the VDU function and then replication
will start working again and complete. Here we rely on exponential backoffs
which were introduced with the scheduling replicator work. At the maximum
backoff interval replications would retry about once every 8 hours.
After the failure is handled and bubbles up to the main replication job process,
there is an attempt to checkpoint before exiting with the error. That is done
in order to reduce change feed reprocessing during each retry attempt.
- [x] Code is written and works correctly;
- [x] Changes are covered by tests;
- [ ] Documentation reflects the changes;
Will make a separate PR for documentation
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services