Repository navigation
Conversation
Move the serialization and deserialization of the log sorting task to an object to make future changes easier. RecoveryManager and LogSorter were depending on the format of the string to be the same. Updated the string to include the sortId and include changes in the upgrade code to rewrite existing ZooKeeper paths to include the sortId.
| * The information needed to sort a write-ahead log, and its representation in the recovery work | ||
| * queue. | ||
| */ | ||
| public record LogSortWork(UUID sortId, String source, String destination) { |
There was a problem hiding this comment.
Looking at how the code works end to end I found that the uuid and destination can be derived from the source. Below shows how these could be derived using existing code that I found.
sortId = LogEntry.fromPath(source).getUniqueID()
destination = RecoveryPath.getRecoveryPath(new Path(source));It may, not sure, be cleaner to push the existing LogEntry type further into the recovery code instead of introducing this new LogSortWork type. May be able to fold the RecoveryPath code into LogEntry as a new LogEntry.getRecoveryPath() method. The only thing we really need to store in the ZK dist queue is the source, do not have to store the uuid and dest since those can be derived. However if the log SPI changes would result in the source and destination possibly being on different volumes that could change this, then maybe the soruce and dest are needed in ZK but not the sortId.
After sorting a log, the tserver code that does recovery is given the source (from the metadata table) and it derives the destination path from the source.
There was a problem hiding this comment.
I can look at using the LogEntry type in more places rather than introducing the LogSortWork class. I just wanted to centralize the writing and reading of the String that we put in ZooKeeper in one place. In #6598 I'm modifying this String to add the WalProviderId.
There was a problem hiding this comment.
The LogEntry has the required information for serializing to, and de-serializing from, the tablet metadata. If we added the destination path to LogEntry to also serialize to ZooKeeper, then we would also need to capture this information in the metadata entry.
The LogEntry is inserted into the tablet metadata when the tserver dies, and the destination path is determined at a different time by the RecoveryManager. We would need to change the existing recovery logic and serialization into the logs tablet metadata entry to store the walog and predetermined sorted log destination. I feel like that's going to end up being a much bigger change.
Move the serialization and deserialization of the log sorting task to an object to make future changes easier. RecoveryManager and LogSorter were depending on the format of the string to be the same.
Updated the string to include the sortId and include changes in the upgrade code to rewrite existing ZooKeeper paths to include the sortId.