backupccl: support RESTORE inside tenant #58908
Conversation
|
This change is |
pbardea
force-pushed
the
restore-tenant
branch
3 times, most recently
from
322598b
to
a0fe7b4
Compare
pbardea
force-pushed
the
restore-tenant
branch
2 times, most recently
from
60d8264
to
8b87c88
Compare
pbardea
force-pushed
the
restore-tenant
branch
5 times, most recently
from
f97b068
to
b3d2cfb
Compare
pkg/ccl/backupccl/restore_job.go
Outdated
| backupCodec := keys.SystemSQLCodec | ||
| if len(sqlDescs) != 0 { | ||
| if len(latestBackupManifest.Spans) != 0 { | ||
| _, tenantID, err := keys.DecodeTenantPrefix(latestBackupManifest.Spans[0].Key) |
There was a problem hiding this comment.
I wonder if we should confirm that all spans, or at least the last span, has the same tenant ID? just thinking to be defensive about backups that contain spans from multiple tenants, where it is unclear that the first is the right one?
There was a problem hiding this comment.
Good point. Although I think that a backup that has no tenant targets would ensure that the entire keyspace covered by manifest.Spans belongs to 1 tenant?
pbardea
force-pushed
the
restore-tenant
branch
3 times, most recently
from
7a9af33
to
aabf4aa
Compare
This commit adds the ability for the key rewriter to rekey keys from one tenant (including the system tenant), into another. Release note: None
pbardea
force-pushed
the
restore-tenant
branch
from
aabf4aa
to
74846ed
Compare
This commit adds support for RESTORE inside tenants. A RESTORE performed by a tenant will produce a DistSQL plan that is planned on a single node. Release note: None
pbardea
force-pushed
the
restore-tenant
branch
from
74846ed
to
59329da
Compare
|
At this point, this PR supports restoring backups taken from tenants into other tenants (but not the system tenant). In order to support restoring backups taken in tenant into the system tenant, we'll need to pass in more information into the rekeyer to tell it if we want to rekey the tenant or not. I think that what is currently supported addresses enough of a use-case to be merged on its own, and can address rekeying to the system tenant in a separate PR. All to say, this should be RFAL. |
|
Friendly ping |
|
TFTR! |
|
Build succeeded: |
This commit adds support for RESTORE inside tenants. A RESTORE performed
by a tenant will produce a DistSQL plan that is planned on a single
node.
Since we don't make note during the backup if we're backing up inside a tenant
or not, we check for every key that we rekey if we're in a new tenant. This is a bit
wasteful -- it would be nice if we could make this determination when we create
the rekeyer.
I suppose that if we can make the assumption that all keys will lie in the same
tenant-space, we can do some checks on the first key and save our learnings
to avoid repetitive work on every key.
Closes #47970.
Release note: None