Closed ZuLiangWang closed 1 year ago
Merging #218 (16513ee) into main (7f1354e) will increase coverage by
20.48%
. The diff coverage is57.51%
.:exclamation: Current head 16513ee differs from pull request most recent head b3f7fb1. Consider uploading reports for the commit b3f7fb1 to get more accurate results
@@ Coverage Diff @@
## main #218 +/- ##
===========================================
+ Coverage 39.66% 60.14% +20.48%
===========================================
Files 34 43 +9
Lines 4213 5144 +931
===========================================
+ Hits 1671 3094 +1423
+ Misses 2317 1656 -661
- Partials 225 394 +169
Impacted Files | Coverage Δ | |
---|---|---|
pkg/coderr/code.go | 0.00% <ø> (ø) |
|
server/cluster/metadata/types.go | 0.00% <0.00%> (ø) |
|
server/coordinator/procedure/util.go | 0.00% <ø> (ø) |
|
server/storage/meta.go | 0.00% <ø> (ø) |
|
server/storage/storage_impl.go | 57.21% <0.00%> (-5.10%) |
:arrow_down: |
server/member/watch_leader.go | 40.62% <20.00%> (-2.71%) |
:arrow_down: |
server/cluster/manager.go | 38.96% <23.52%> (ø) |
|
server/coordinator/factory.go | 76.68% <27.27%> (+72.22%) |
:arrow_up: |
.../operation/transferleader/batch_transfer_leader.go | 33.80% <33.80%> (ø) |
|
server/member/member.go | 47.39% <45.00%> (-1.32%) |
:arrow_down: |
... and 20 more |
Which issue does this PR close?
Closes #
Rationale for this change
At present, our implementation of shard opening is relatively simple. When some tables in a shard fail to open, it is impossible to retry and recover without restarting the CeresDB node. We need to solve this problem so that shards that fail to open some tables Can be recovered by retrying.
What changes are included in this PR?
ReopenShardScheduler
for retrying partially opened shards.Are there any user-facing changes?
None.
How does this change test