-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Revisit deletion policy after release the last snapshot #28627
Revisit deletion policy after release the last snapshot #28627
Conversation
A follow-up of elastic#28140 We currently revisit the index deletion policy whenever the global checkpoint has advanced enough. However, we won't be able to clean up the old commit points if they are being snapshotted. Here we prefer a simple solution over an optimal solution as we should revisit if only the last commit is being snapshotted.
@@ -235,7 +239,7 @@ private static int indexOfKeptCommits(List<? extends IndexCommit> commits, long | |||
*/ | |||
boolean hasUnreferencedCommits() throws IOException { | |||
final IndexCommit lastCommit = this.lastCommit; | |||
if (safeCommit != lastCommit) { // Race condition can happen but harmless | |||
if (safeCommit != lastCommit && pendingSnapshots == 0) { // Race condition can happen but harmless |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really follow this logic? safe commit is maintained outside of the real of snapshots? shouldn't these be two different things? also, we now call this method when the translog is synced and thus potentially something changed for the safe commit. That doesn't have much todo with snapshots and the chance of them being released. Maybe we should make release commit return a boolean and use that an indication that there are commits that can be cleaned up?
@bleskes I've updated the PR according to our discussion. Can please have another look? Thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some minor questions.
@s1monw wdyt about this?
@@ -178,6 +180,8 @@ synchronized void releaseCommit(final IndexCommit snapshotCommit) { | |||
if (refCount == 0) { | |||
snapshottedCommits.remove(releasingCommit); | |||
} | |||
// The commit can be clean up only if no pending snapshot and it is not the last commit. | |||
return refCount == 0 && releasingCommit.equals(lastCommit) == false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't we need a similar check for the safe commit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it should return false if the releasing snapshot is the safe commit.
assertThat(DirectoryReader.listCommits(store.directory()), contains(safeCommit, lastCommit)); | ||
for (int i = 0; i < numSnapshots - 1; i++) { | ||
snapshots.get(i).close(); | ||
assertThat(DirectoryReader.listCommits(store.directory()), contains(safeCommit, lastCommit)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to check nothing is cleaned just yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the assertion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am good with this.
# Conflicts: # server/src/main/java/org/elasticsearch/index/engine/InternalEngine.java
We currently revisit the index deletion policy whenever the global checkpoint has advanced enough. We should also revisit the deletion policy after releasing the last snapshot of a snapshotting commit. With this change, the old index commits will be cleaned up as soon as possible. Follow-up of #28140 #28140 (comment)
* master: Enable selecting adaptive selection stats Remove leftover mention of file-based scripts Fix threading issue on listener notification (elastic#28730) Revisit deletion policy after release the last snapshot (elastic#28627) Remove unused method Track deletes only in the tombstone map instead of maintaining as copy (elastic#27868) [Docs] Correct typo in README.textile (elastic#28716) Fix AdaptiveSelectionStats serialization bug (elastic#28718) TEST: Fix InternalEngine#testAcquireIndexCommit Add note on temporary directory for Windows service Added coming annotation and breaking changes link to release notes script Remove leftover PR link for previously disabled bwc tests Separate acquiring safe commit and last commit (elastic#28271) Fix BWC issue of the translog last modified age stats
A follow-up of #28140 (see #28140 (comment))
We currently revisit the index deletion policy whenever the global checkpoint has advanced enough. We should also revisit the deletion policy after releasing the last snapshot of a snapshotting commit. With this change, the old index commits will be cleaned up as soon as possible.