-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Enforce retention policies #1562
Conversation
This is work-in-progress, as I have some questions about this untested implementation, and also need to add unit-testing. |
A summary of the implementation follows. Each data node runs the "retention policy enforcement" loop, and looks for shard groups within each Retention Policy, which have an "end time", plus the retention period, earlier than now. For all matching shard groups, a command is sent to the Raft cluster, requesting deletion of this shard group. Each data node, upon receipt of this command, deletes any shards it has associated with this shard group, and updates its local copy of the metastore. Because all data nodes will run the loop, it does mean that multiple deletion commands may be generated for a given shard group (when its end time passes) -- the data nodes account for this by simply ignoring requests to delete non-existent shard groups. |
388d3dc
to
cb3d19f
Compare
} | ||
|
||
// Remove from metastore. | ||
rp.removeShardGroupByID(c.ID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is these lines I have questions about for @benbjohnson around serlialization of database meta to metastore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Answered by @benbjohnson and fixed by beefdee
Unit tests added, green build. Still need to perform some system testing. |
bd478c8
to
f544bea
Compare
MaxOpenShards int `toml:"max-open-shards"` | ||
PointBatchSize int `toml:"point-batch-size"` | ||
WriteBatchSize int `toml:"write-batch-size"` | ||
Engines map[string]toml.Primitive `toml:"engines"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should just remove the WriteBufferSize
, MaxOpenShards
, PointBatchSize
, WriteBatchSize
, and Engines
members on the Data
struct
One small comment, but other than that LGTM |
If shard groups were stored in a map by ID, this lookup could be sped up.
I performed a system test this morning, using an actual
Queries of data in short returned no results, but queries of data in long did. |
f544bea
to
19cd550
Compare
This appears to be an integration test failure, I haven't seen it before. The integration tests may still be racy. I'll kick Travis and try again. |
Green build, we appear to have some racy tests. This is currently captured by issue #1556. |
for _, db := range s.databases { | ||
for _, rp := range db.policies { | ||
for _, g := range rp.shardGroups { | ||
if g.EndTime.Add(rp.Duration).Before(time.Now()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be using UTC here, otherwise it's going to be off if their server isn't set to that.
Fixed the task id path, Added RunController instance to pAdapter
Fixes merge issue from #1562
No description provided.