-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
backupccl: move alloc heavy Files field from manifest to SST
Repeated fields in a backup's manifest do not scale well as the amount of backed up data, and the length of the incremental chain of backup grows. This has been a problem we have been aware of, and has motivated us to incrementally move all repeated fields out of the manifest and into their standalone metadata SST files. The advantage of this is that during incremental backups or restores we do not need to perform large allocations when unmarshalling the manifest, but instead stream results from the relevant SST as and when we need them. In support issues such as #93272 we have seen this unmarshalling step results in OOMs thereby preventing further incremental backups, or making the backups unrestoreable. Efforts for moving backup, and restore to have all their metadata in SSTs and rely on streaming reads and writes is ongoing but outside the scope of this patch. This patch is meant to be a targetted fix with an eye for backports. Past experimentation has shown us that the `Files` repeated field in the manifest is the largest cause of bloated, unmarshalable manifests. This change teaches backup to continue writing a manifest file, but a slimmer one with the `Files` field nil'ed out. The values in the `Files` field are instead written to an SST file that sits alongside the `SLIM_BACKUP_MANIFEST`. To maintain mixed-version compatability with nodes that rely on a regular manifest, we continue to write a `BACKUP_MANIFEST` alongside its slim version. On the read path, we add an optimization that first reads the slim manifest if present. This way we avoid unmarshalling the alloc heavy `Files` field, and instead teach all the places in the code that need the `Files` to reach out to the metadata SST and read the values one by one. To support both the slim and not-so-slim manifests we introduce an interface that iterates over the Files depending on the manifest passed to it. To reiterate, this work is a subset of the improvements we will get from moving all repeated fields to SSTs and is expected to be superseded by those efforts when they come to fruition. Fixes: #93272 Release note (performance improvement): long chains of incremental backups and restore of such chains will now allocate less memory during the unmarshaling of metadata
- Loading branch information
1 parent
6c619e2
commit 60f4783
Showing
10 changed files
with
535 additions
and
89 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.