-
Notifications
You must be signed in to change notification settings - Fork 646
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
[Tracking Issue] Flat storage for resharding V3 #12174
Comments
merged #12164 tackling the introduction of |
4 tasks
merged #12223 to handle all key types |
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 17, 2024
Adding log entries telling the time spent on the longer operations happening during flat storage resharding. Part of flat storage resharding issue (#12174).
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 21, 2024
Implementation of flat storage deltas split for flat storage resharding. Before this change, only flat storage key pairs at flat head height were split during resharding. Now flat storage deltas are part of the splitting process as well. On a high level, it works by concatenating the iterator over flat storage and the iterator over deltas for all block heights between chain head an flat storage head. Part of #12174
github-merge-queue bot
pushed a commit
that referenced
this issue
Nov 4, 2024
PR to add children catchup step for flat storages created as a result of a parent shard split. In previous iterations, the two children shards were populated in a background task from the flat storage of the parent at height `last block of old shard layout` (post-processing). Since the task mentioned above takes a long time and the children are active shards in the `first block of the new shard layout` their flat storage accumulates a lot of deltas. The catchup step applies delta in the background, then finalizes creation of child flat storage, and triggers a possible memtrie rebuild. Part of #12174
github-merge-queue bot
pushed a commit
that referenced
this issue
Nov 11, 2024
…ock is final (#12415) Contents of this PR: - New features - Actual splitting of flat storage is delayed until the target resharding block becomes final - Scheduled resharding event can be overridden. This makes resharding work in many chain fork scenarios (not all of them though) - Added `FlatStorageReshardingTaskSchedulingStatus` to express the current state of scheduled tasks waiting for resharding block finality - Changes - Shard catchup doesn't wait anymore for resharding block finality. It is now a consequence of the fact that the shard split happens on a final block. - `FlatStorageReshardingTaskStatus` renamed into `FlatStorageReshardingTaskResult` for clarity - `ReshardingActor` now takes care of re-trying "postponed" tasks. Part of #12174
github-merge-queue bot
pushed a commit
that referenced
this issue
Dec 11, 2024
Adding two new metrics to monitor resharding: - `near_flat_storage_resharding_status` - `near_flat_storage_resharding_split_shard_processed_batches` Reusing the existing metric `near_flat_storage_head_height` to monitor shard catchup. Part of #12174
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Part of #11881
Goal
Support resharding V3 for Flat Storage. On shard layout, Flat Storage must be able to take a shard and split it into two children.
The entire process will happen in the background with no strict time requirement. Additional processing resources consumption should be minimal because, in the meantime, the node will continue to apply blocks and chunks.
Sub-tasks
[ ] Double signing corner casesWe decided to not implement any safeguard. The scenario is very rare and impacted node can be recovered from an healthy snapshot.
Tests
Nice to have
The text was updated successfully, but these errors were encountered: