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

Always use Lucene index in peer recovery #2077

Merged

Conversation

nknize
Copy link
Collaborator

@nknize nknize commented Feb 9, 2022

With soft deletes no longer optional, this PR switches peer recovery to always use the
lucene index instead of replaying operations from the translog. This reduces disk footprint
and storage costs for the end user by relying on improved stored fields compression. Note
there is a slight CPU performance penalty that has recently been improved in recent releases
of lucene
. For now we accept the CPU performance penalty in trade for smaller disk footprint
and storage cost. If desired we can explore offering both options that are selectable by an
expert setting (similar to index.codec).

With soft deletes no longer optional, peer recovery is switched to always use the
lucene index instead of replaying operations from the translog.

Signed-off-by: Nicholas Walter Knize <[email protected]>
@nknize nknize added enhancement Enhancement or improvement to existing feature or request v2.0.0 Version 2.0.0 Storage:Durability Issues and PRs related to the durability framework labels Feb 9, 2022
@nknize nknize requested a review from a team as a code owner February 9, 2022 14:48
@opensearch-ci-bot
Copy link
Collaborator

Can one of the admins verify this patch?

@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Check success 55881a1
Log 2307

Reports 2307

@dblock dblock requested review from andrross and mch2 February 9, 2022 16:30
@nknize
Copy link
Collaborator Author

nknize commented Feb 22, 2022

I'm getting ready to remove types from the translog....having this PR merged will help prevent me from having to carry some unnecessary code to handle types in recovery from translog.

Can someone please review / approve to help get this in relatively soon? /cc @CEHENKLE @andrross

resources.add(retentionLock);
final long startingSeqNo;
final boolean isSequenceNumberBasedRecovery = request.startingSeqNo() != SequenceNumbers.UNASSIGNED_SEQ_NO
&& isTargetSameHistory()
&& shard.hasCompleteHistoryOperations("peer-recovery", historySource, request.startingSeqNo())
&& (historySource == Engine.HistorySource.TRANSLOG
&& shard.hasCompleteHistoryOperations("peer-recovery", request.startingSeqNo())
Copy link
Collaborator

Choose a reason for hiding this comment

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

Very difficult to follow this ifs forest, may be a few intermediate booleans would help?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think I'd rather do that in a follow up because some of this is going to get refactored away anyway with coming segrep changes

Signed-off-by: Nicholas Walter Knize <[email protected]>
@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Check success 6f20e72
Log 2735

Reports 2735

shard.estimateNumberOfHistoryOperations("peer-recovery", historySource, startingSeqNo)
);
final Translog.Snapshot phase2Snapshot = shard.getHistoryOperations("peer-recovery", historySource, startingSeqNo);
logger.trace("snapshot translog for recovery; current size is [{}]", estimateNumberOfHistoryOperations(startingSeqNo));
Copy link
Member

Choose a reason for hiding this comment

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

This isn't directly related to the change here, but would it be better to refactor this logging statement so that estimateNumberOfHistoryOperations() only gets computed if trace logging is actually enabled? It looks like that method is doing a non-trivial amount of work. I don't know the context in which this is called to know if it would make any practical difference though.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

💯 Good catch! Wrapped in logger.isTraceEnabled()

Signed-off-by: Nicholas Walter Knize <[email protected]>
@opensearch-ci-bot
Copy link
Collaborator

✅   Gradle Check success 8a21554
Log 2747

Reports 2747

@nknize nknize merged commit 44441d8 into opensearch-project:main Feb 23, 2022
@saratvemulapalli
Copy link
Member

@nknize / @andrross / @reta looks like we have removed getHistoryOperations.
Is there an alternative way to get the history on index ?
Looks like #2482 CCR plugin depends on it to understand the changes and replicate.

@reta
Copy link
Collaborator

reta commented Mar 17, 2022

@nknize / @andrross / @reta looks like we have removed getHistoryOperations.

@saratvemulapalli hm ... it is there but signature has changed a bit:

  public Translog.Snapshot getHistoryOperations(String reason, long startingSeqNo, long endSeqNo) throws IOException {

@nknize
Copy link
Collaborator Author

nknize commented Mar 17, 2022

Correct. Just add true for accurate counts.

Note that I almost removed this because it isn't used anywhere in core. I kept it around in case plugins (e.g., CCR) need it. We might consider refactoring to the CCR plugin if it's the only one that uses it, or we can refactor to common-utils module if we need to reuse across plugins.

@saratvemulapalli
Copy link
Member

@nknize / @andrross / @reta looks like we have removed getHistoryOperations.

@saratvemulapalli hm ... it is there but signature has changed a bit:

  public Translog.Snapshot getHistoryOperations(String reason, long startingSeqNo, long endSeqNo) throws IOException {

Sorry I should have been more specific. CCR was depending on getHistoryOperations based on Engine.HistorySource.

@nknize
Copy link
Collaborator Author

nknize commented Mar 17, 2022

@nknize / @andrross / @reta looks like we have removed getHistoryOperations.

@saratvemulapalli hm ... it is there but signature has changed a bit:

  public Translog.Snapshot getHistoryOperations(String reason, long startingSeqNo, long endSeqNo) throws IOException {

Sorry I should have been more specific. CCR was depending on getHistoryOperations based on Engine.HistorySource.

Since soft deletes are no longer optional, Translog is also no longer an option for HistorySource. We now always use the Lucene Index per this PR.

@saratvemulapalli
Copy link
Member

@nknize / @andrross / @reta looks like we have removed getHistoryOperations.

@saratvemulapalli hm ... it is there but signature has changed a bit:

  public Translog.Snapshot getHistoryOperations(String reason, long startingSeqNo, long endSeqNo) throws IOException {

Sorry I should have been more specific. CCR was depending on getHistoryOperations based on Engine.HistorySource.

Since soft deletes are no longer optional, Translog is also no longer an option for HistorySource. We now always use the Lucene Index per:

#2077

So if I understand this correctly, the only way for plugins to pull history is get the information from lucene index (a.k.a seqNos).
If that assumption is correct, then we are saying CCR has to change to use the new signature and not depend on translog anymore.

@nknize
Copy link
Collaborator Author

nknize commented Mar 17, 2022

CCR has to change to use the new signature and not depend on translog anymore.

CCR has to change to use the new signature, yes, and not depend on the "translog" file as a history source. CCR still gets operations history but it's now from the lucene operations index instead of the translog file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Enhancement or improvement to existing feature or request Storage:Durability Issues and PRs related to the durability framework v2.0.0 Version 2.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants