engine_rocks: introduce force_partition_range in compact guard#18866
engine_rocks: introduce force_partition_range in compact guard#18866ti-chi-bot[bot] merged 12 commits intotikv:masterfrom
force_partition_range in compact guard#18866Conversation
Signed-off-by: glorv <glorvs@163.com>
Signed-off-by: glorv <glorvs@163.com>
Signed-off-by: glorv <glorvs@163.com>
Signed-off-by: glorv <glorvs@163.com>
Signed-off-by: glorv <glorvs@163.com>
Signed-off-by: glorv <glorvs@163.com>
| &[] | ||
| }; | ||
|
|
||
| tikv_util::info!("sst partition due to force partition ranges"; |
There was a problem hiding this comment.
It seems that self.current_next_level_size >= self.max_compaction_size may also bring us here. I know it is just for logging, but do we need to distinguish it?
|
|
||
| // ingest a sst with a big range | ||
| let (mut meta, data) = | ||
| gen_sst_file_with_tidb_kvs(sst_path.clone(), &[(b"a", b"a"), (b"z", b"z")], None); |
There was a problem hiding this comment.
Insteading of ingest a generated SST, how about writing to TiKV with txn APIs. Because there is a key encoding logic in add_force_partition_range
There was a problem hiding this comment.
Yes, this is a tricky workaround, because we need to write a large amount of data to let rocksdb trigger flush and generate sst files. So I just let gen_sst_file_with_tidb_kvs generate the rocksdb format data kv, there should be no difference.
[LGTM Timeline notifier]Timeline:
|
| let ttl = r.ttl.saturating_duration_since(now); | ||
| if ttl == Duration::ZERO { |
There was a problem hiding this comment.
nit: use a consistent style for time comparison
| let ttl = r.ttl.saturating_duration_since(now); | |
| if ttl == Duration::ZERO { | |
| let expired = r.ttl < now; | |
| if expired { |
| struct TtlRange { | ||
| start: Vec<u8>, | ||
| end: Vec<u8>, | ||
| ttl: Instant, |
There was a problem hiding this comment.
nit: TTL usually means a duration rather than a time point. expires_at is probably better.
| ttl: Instant, | |
| expires_at: Instant, |
Signed-off-by: glorv <glorvs@163.com>
|
/hold waiting for pingcap/kvproto#1340 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Connor1996, v01dstar, zhangjinpeng87 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
…v#18866) close tikv#18865 - introduce `force_partition_range` in compact guard to force partition specific range to ensure SST ingestion under this range can be ingested to the bottom level. - Add 2 new API in SST service to manage the `force_partition_range`. The `add_force_partition_range` will also trigger a manual compaction to ensure existing SST will be partitioned. Signed-off-by: glorv <glorvs@163.com>
close tikv#18912 Fix the incorrect assert of compaction guard introduced by tikv#18866. Signed-off-by: glorv <glorvs@163.com>
close tikv#18865 Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
|
In response to a cherrypick label: new pull request created to branch |
close tikv#18865 Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
|
In response to a cherrypick label: new pull request created to branch |
close tikv#18865 Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
|
In response to a cherrypick label: new pull request created to branch |
close tikv#18912 Fix the incorrect assert of compaction guard introduced by tikv#18866. Signed-off-by: glorv <glorvs@163.com>
) (#18934) close #18865 - introduce `force_partition_range` in compact guard to force partition specific range to ensure SST ingestion under this range can be ingested to the bottom level. - Add 2 new API in SST service to manage the `force_partition_range`. The `add_force_partition_range` will also trigger a manual compaction to ensure existing SST will be partitioned. Signed-off-by: glorv <glorvs@163.com> Signed-off-by: lucasliang <nkcs_lykx@hotmail.com> Co-authored-by: glorv <glorvs@163.com> Co-authored-by: lucasliang <nkcs_lykx@hotmail.com>
…v#18866) close tikv#18865 - introduce `force_partition_range` in compact guard to force partition specific range to ensure SST ingestion under this range can be ingested to the bottom level. - Add 2 new API in SST service to manage the `force_partition_range`. The `add_force_partition_range` will also trigger a manual compaction to ensure existing SST will be partitioned. Signed-off-by: glorv <glorvs@163.com> Signed-off-by: 3AceShowHand <jinl1037@hotmail.com>
close tikv#18912 Fix the incorrect assert of compaction guard introduced by tikv#18866. Signed-off-by: glorv <glorvs@163.com> Signed-off-by: 3AceShowHand <jinl1037@hotmail.com>
…v#18866) close tikv#18865 - introduce `force_partition_range` in compact guard to force partition specific range to ensure SST ingestion under this range can be ingested to the bottom level. - Add 2 new API in SST service to manage the `force_partition_range`. The `add_force_partition_range` will also trigger a manual compaction to ensure existing SST will be partitioned. Signed-off-by: glorv <glorvs@163.com>
close tikv#18912 Fix the incorrect assert of compaction guard introduced by tikv#18866. Signed-off-by: glorv <glorvs@163.com>
What is changed and how it works?
Issue Number: Close #18865
What's Changed:
Related changes
pingcap/docs/pingcap/docs-cn:Check List
Tests
Side effects
Release note