New downstairs clone subcommand. #1129
Conversation
This enables a downstairs to "clone" another downstairs using the repair endpoint. It requires the source downstairs to be read only and will destroy whatever data exists on the destination downstairs. Support for cloning SQLite backend downstairs is supported, and I had to bring back some of the old repair code that supported the additional files for that. Found an fixed a bug where the incorrect file types were returned during a repair that contained SQLite files. A bunch more tests were added to cover the clone process, and new API endpoints were added to the downstairs repair server.
downstairs/src/region.rs
Outdated
| all.extend(vec![ | ||
| extent_file_name(eid as u32, ExtentType::DbShm), | ||
| extent_file_name(eid as u32, ExtentType::DbWal), | ||
| ]); |
There was a problem hiding this comment.
Are these always guaranteed to be in the same order? Using a BTreeSet<String> or similar would make it more obvious that the comparison is meant to be order-agnostic.
There was a problem hiding this comment.
We always produce them in the same order, so assuming extent_file_list()'s into_iter() call
will walk the vec provided to it in order, then I suppose it's safe to expect that order never
changes?
We also (and I'm not sure why any longer) call repair_files.sort() over in
downstairs/src/region.rs, so even if the remote side does not produce the files in order, we
sort them on the requesting side.
Now that I think about it, I wonder if that repair_files.sort() in downstairs/src/region.rs was
attempting to work around the bug in the file type translation, where we had mixed db-shm
and db-wal.
|
Fixes #1018 |
|
This is almost good to go; my only remaining comment is fixing the remaining instances of "compatable" |
| false, | ||
| false, | ||
| false, | ||
| false, | ||
| true, // read_only |
There was a problem hiding this comment.
Maybe it's time for the builder pattern... 🙃
There was a problem hiding this comment.
Made a new PR for just that:
#1152
Add support for a new downstairs clone subcommand.
This enables a downstairs to "clone" another downstairs using the
repair endpoint. It requires the source downstairs to be read only
and will destroy whatever data exists on the destination downstairs.
Support for cloning SQLite backend downstairs is supported, and I had
to bring back some of the old repair code that supported the additional
files for that. The resulting clone'd downstairs will still have a SQLite
backend.
Found an fixed a bug where the incorrect file types were returned
during a repair that contained SQLite files.
A bunch more tests were added to cover the clone process, and new
API endpoints were added to the downstairs repair server.
The is the base layer we need to support replacement of read only parents.
For that the workflow up in omicron will be to:
don't run the downstairs once the region is created.
the good downstairs.