-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
embed: value of AutoCompactionRetention and embed.CompactorModeRevision are incompatible #9337
Comments
Also, I'd assume this isn't just affecting embedded etcd, but have not loooked into how the command line does it for etcd. |
@grepory How do you configure We define
If you need periodic compaction, you can: // auto-compaction every hour
cfg.AutoCompactionMode = embed.CompactorModePeriodic
cfg.AutoCompactionRetention = "1h" If you need revision-based compaction, you can: // auto-compaction every 5000 rev
cfg.AutoCompactionMode = embed.CompactorModeRevision
cfg.AutoCompactionRetention = "5000" I don't think you need to convert |
AutoCompactionRetention gets cased to a time.Duration no matter what mode you specify. At some point, that value gets multiplied by time.Hour -- at which point 5000 becomes 5000 hours which gets converted to an int64 -- which is much more than 5000 revisions. Right now, we're doing this: // Every 5 minutes, we will prune all values in etcd to only their latest
// revision.
cfg.AutoCompactionMode = embed.CompactorModeRevision
// This has to stay in ns until https://github.com/coreos/etcd/issues/9337
// is resolved.
cfg.AutoCompactionRetention = "1ns" Specifying only "1" in AutoCompactionRetention ended up specifying a revision count of 3600000000000. Again, where this happens is here: 1 hour does not translate to 1 revision. |
Oh now I see the issue.
Thanks for the report. We will fix this soon! /cc @fanminshi |
No problem! Thanks for looking into it. :) <3 |
Specifying embed.CompactorModeRevision for the configuration's AutoCompactionMode parameter will result in an unintentional value for the revision compactor's retention parameter.
Because of the treatment of retention as a time.Duration and its conversion here -- we end up passing a 1 hour time.Duration and converting it to an int64 via
int64(retention)
, which tells the revision compactor to only compact after revision 3600000000000.To get around this, we're specifying the retention value for CompactorModeRevision in nanoseconds which parses as a "1ns" -> 1, for example.
The text was updated successfully, but these errors were encountered: