Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore local history from translog on promotion #33616

Merged
merged 7 commits into from
Sep 20, 2018

Conversation

dnhatn
Copy link
Member

@dnhatn dnhatn commented Sep 12, 2018

If a shard was serving as a replica when another shard was promoted to
primary, then its Lucene index was reset to the global checkpoint.
However, if the new primary fails before the primary/replica resync
completes and we are now being promoted, we have to restore the reverted
operations by replaying the translog to avoid losing acknowledged writes.

Relates #33473
Relates #32867

If a shard was serving as a replica when another shard was promoted to
primary, then its Lucene index was reset to the global checkpoint.
However, if the new  primary fails before the primary/replica resync
completes and we are now being promoted, we have to restore the reverted
operations by replaying the translog to avoid losing acknowledged writes.

Relates elastic#32867
@dnhatn dnhatn added >enhancement :Distributed Indexing/Recovery Anything around constructing a new shard, either from a local or a remote source. v7.0.0 v6.5.0 labels Sep 12, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

localCheckpointTracker.markSeqNoAsCompleted(operation.seqNo());
}
}
return translogRecoveryRunner.run(this, snapshot);
Copy link
Member Author

@dnhatn dnhatn Sep 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can keep track a max_seqno from translog to recover when we rollback this engine (i.e., recover_upto and max_seqno in translog at that time), then only restore if needed. However, I opted out for simplicity.

@@ -341,7 +341,9 @@ public void rollTranslogGeneration() {
}

@Override
public void restoreLocalCheckpointFromTranslog() {
public int restoreLocalHistoryFromTranslog(TranslogRecoveryRunner translogRecoveryRunner) {
assert false : "this should not be called";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why this throws an exception. if you have an index that is read-only and uses this engine and a primary get's promoted this should be a no-op not a UOE?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we should make this a no-op (just like fillSeqNoGaps).

@dnhatn dnhatn requested a review from s1monw September 12, 2018 11:58
@dnhatn dnhatn added the review label Sep 12, 2018
Copy link
Contributor

@s1monw s1monw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but I think @bleskes needs to take a look too

dnhatn added a commit that referenced this pull request Sep 13, 2018
dnhatn added a commit that referenced this pull request Sep 13, 2018
Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks @dnhatn

@dnhatn
Copy link
Member Author

dnhatn commented Sep 20, 2018

Thanks @s1monw and @ywelsch.

dnhatn added a commit that referenced this pull request Sep 20, 2018
If a shard was serving as a replica when another shard was promoted to
primary, then its Lucene index was reset to the global checkpoint.
However, if the new primary fails before the primary/replica resync
completes and we are now being promoted, we have to restore the reverted
operations by replaying the translog to avoid losing acknowledged writes.

Relates #33473
Relates #32867
kcm pushed a commit that referenced this pull request Oct 30, 2018
If a shard was serving as a replica when another shard was promoted to
primary, then its Lucene index was reset to the global checkpoint.
However, if the new primary fails before the primary/replica resync
completes and we are now being promoted, we have to restore the reverted
operations by replaying the translog to avoid losing acknowledged writes.

Relates #33473
Relates #32867
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Indexing/Recovery Anything around constructing a new shard, either from a local or a remote source. >enhancement v6.5.0 v7.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants