Skip to content
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

backupccl: check revision start time #22659

Merged
merged 1 commit into from Feb 14, 2018
Merged

backupccl: check revision start time #22659

merged 1 commit into from Feb 14, 2018

Conversation

dt
Copy link
Member

@dt dt commented Feb 13, 2018

Record the revision start time, which may not be the same as the start
time, namely in full backups where start time is 0 but revision history
obviously can only be captured since the GC threshold. The backup
records the latest safe time and then restore checks that requested
times are after that.

Release note (enterprise change): Check that backup actually contains requested restore time.

@dt dt requested review from maddyblue, danhhz and a team February 13, 2018 19:32
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Record the revision start time, which may not be the same as the start
time, namely in full backups where start time is 0 but revision history
obviously can only be captured since the GC threshold. The backup
records the latest safe time and then restore checks that requested
times are after that.

Fixes cockroachdb#19455.

Release note (enterprise change): Check that backup actually contains requested restore time.
@dt
Copy link
Member Author

dt commented Feb 13, 2018

Note that this is stricter than it technically needs to be -- we could store per-span times and then just look at those spans needed when we restore. Probably only really makes a big difference though in the case where your tables have greatly different retention policies, and you'd still have the option of backing them up separately too or taking incremental more often, so I'm not sure it is worth the extra complexity yet.

@dianasaur323
Copy link
Contributor

I think probably not, since there is the workaround of just doing 2 separate backups for those different tables. At some point, we could do some really user friendly stuff here, but probably not worth the time right now.

@dt dt merged commit 18decce into cockroachdb:master Feb 14, 2018
@dt dt deleted the mvcc branch February 14, 2018 12:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants