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
Handle old sorted map files in Upgrade #2185
Conversation
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.
Everything looks good. Noticed one small typo but that is about it.
server/manager/src/main/java/org/apache/accumulo/manager/upgrade/Upgrader9to10.java
Outdated
Show resolved
Hide resolved
server/manager/src/main/java/org/apache/accumulo/manager/Manager.java
Outdated
Show resolved
Hide resolved
server/manager/src/main/java/org/apache/accumulo/manager/upgrade/Upgrader9to10.java
Show resolved
Hide resolved
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.
Everything looks good from my perspective. Have you done any testing to verify that Accumulo will automatically re-sort the WALs once these are deleted? Any way to create a test for that?
Yeah I did some manual testing with Uno. It may be possible to create an IT with the old files saved off but I imagine it would be quite involved. I am not sure its worth the work for a one time thing that will only ever happen between versions. |
* Add upgradeFiles method for upgrading files to Upgrader * Refactor status handling in UpgradeCoordinator to allow upgradeFiles to run concurrently and wait for metadata upgrade to complete * Implement upgradeFiles method in Upgrader9to10 * Add dropSortedMapWALFiles for resolving sorted map files that may still be around during upgrade. Follow up for apache#2117 * Closes apache#2179
4a51d7b
to
03e72b3
Compare
@ctubbsii I reverted the changes I made adding a new upgradeFiles method to the Upgrade interface and now this change is much simpler. I believe I got rid of the changes you had concern over. This PR was just the new code I added to fix old sorted logs. |
So I did so more testing and while it successfully deleted the old data, I am not 100% sure that it won't delete WALs that still have referenced data in them. This is a little tricky to test manually, as you need to make sure the table is recovering but also have unloaded tablets (before the data is flushed to disk). I am going to open a ticket to test this using Continuous Ingest. |
* Remove old temporary map files to prevent problems during recovery. | ||
*/ | ||
static void dropSortedMapWALFiles(VolumeManager vm) { | ||
Path recoveryDir = new Path("/accumulo/recovery"); |
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.
Seems like this should loop over the set of configured volumes instead of this.
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.
Good catch. I will create a follow on ticket with this and any other suggestions you have.
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.
Do you think using the volumes configured in instance.volumes
will be enough?
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.
Do you think using the volumes configured in instance.volumes will be enough?
Yeah, could look through all of those. Could narrow it by calling :
accumulo/server/base/src/main/java/org/apache/accumulo/server/fs/VolumeManager.java
Line 180 in a9100ac
Set<String> choosable(org.apache.accumulo.core.spi.fs.VolumeChooserEnvironment env, |
But I don't think it hurts to just look through all volumes. Maybe could use
accumulo/server/base/src/main/java/org/apache/accumulo/server/fs/VolumeManager.java
Line 196 in a9100ac
Collection<Volume> getVolumes(); |
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.
Would probably be best to avoid choosable() as that will give the volumes configured for new WALs. The config could change and an old WAL could be on a volume that choosable() no longer returns. So probably best to inspect all volumes looking for old sorted wals to nuke.
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.
Would probably be best to avoid choosable() as that will give the volumes configured for new WALs. The config could change and an old WAL could be on a volume that choosable() no longer returns. So probably best to inspect all volumes looking for old sorted wals to nuke.
Definitely avoid this. Consider RandomVolumeChooser 😺
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 thought the VolumeChooser was for selecting volumes for writes? I want to loop through every volume configured to find the old sorted WALs to remove. Will the VolumeChooser allow for this?
@@ -142,6 +148,8 @@ public void upgradeMetadata(ServerContext ctx) { | |||
upgradeRelativePaths(ctx, Ample.DataLevel.USER); | |||
upgradeDirColumns(ctx, Ample.DataLevel.USER); | |||
upgradeFileDeletes(ctx, Ample.DataLevel.USER); | |||
// special case where old files need to be deleted |
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.
Did you consider calling this new method in upgradeZookeeper instead? I think that is called before the root tablet is loaded, which would allow deleting any old sorted logs the root tablet may reference.
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.
No, I didn't think any tables were loaded until after the Upgrader was finished. If that is the case, then moving it to upgradeZookeeper
would be better.
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 the upgrade methods are run as follows.
upgradeZookeeper()
is run before the root tablet is loaded.upgradeRoot()
is run after the root tablet is loaded and before the metadata table is loaded.upgradeMetadata
is run after the metadata table is loaded and before loading user tablets.
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.
Ah OK. I will move it to upgradeZookeeper()
.
Capture discussion on PR apache#2185 to update javadoc comments. Doc update only - contains no code changes.
* Follow on work for apache#2185 * Improve upgrade code in Upgrader9to10.dropSortedMapWALFiles() * Add comments to Upgrader interface
* Follow on work for apache#2185 * Improve upgrade code in Upgrader9to10.dropSortedMapWALFiles()
* Follow on work for apache#2185 * Improve upgrade code in Upgrader9to10.dropSortedMapWALFiles()
…pache#2225) * Update interface comments to include expected system state. Capture discussion on PR apache#2185 to update javadoc comments. Doc update only - contains no code changes. * update phrasing per PR comments Co-authored-by: Ed Coleman etcoleman <edcoleman@apache.org>
* Follow on work for apache#2185 * Improve upgrade code in Upgrader9to10.dropSortedMapWALFiles()
* Follow on work for #2185 * Improve upgrade code in Upgrader9to10.dropSortedMapWALFiles()
* Add upgradeFiles method for upgrading files to Upgrader* Refactor status handling in UpgradeCoordinator to allow upgradeFilesto run concurrently and wait for metadata upgrade to complete
* Implement upgradeFiles method in Upgrader9to10still be around during upgrade. Follow up for Make sorted recovery write to RFiles #2117