feat: speed up rollback command#636
Conversation
yihuang
force-pushed
the
master
branch
2 times, most recently
from
d9f40d1 to
9c1abd8
Compare
| return err | ||
| } | ||
|
|
||
| if node.version < version { |
yihuang
requested review from
cool-develope and
mmsqe
and removed request for
cool-develope and
mmsqe
- fully rebuild fast node indexes after rollback, rather than leave it in dirty state. - skip unnecessary subtree traversal when deleting the latest version. - restrict the iteration range when deleting orphans.
| if err != nil { | ||
| return err | ||
| } | ||
| // NOTICE: we don't touch fast node indexes here, because it'll be rebuilt later because of version mismatch. |
There was a problem hiding this comment.
What is the trade off here?
There was a problem hiding this comment.
I believe the previous logic to just delete some fastnodes is simply wrong, because fast node is assumed to be represent the complete live state, it's wrong to leave a partial fast node index.
In new version, fast node index will be fully rebuilt because of version mismatch, and if user don't want to slow down rollback, they can disable fast node index before rollback, after recovered the node operation, user can find another good time to rebuild the fast node index by enable it again.
tac0turtle
left a comment
tac0turtle
left a comment
There was a problem hiding this comment.
Utack. Should we backport this?
I hope so, it's a big UX improvement for existing version. |
|
@Mergifyio backport release/v0.19.x |
(cherry picked from commit d4086fe) # Conflicts: # nodedb.go
✅ Backports have been createdDetails
|
Co-authored-by: yihuang <huang@crypto.com> Co-authored-by: Marko Baricevic <marbar3778@yahoo.com>
6 participants
support LazyLoadVersion, remove lazy support, we might be able to use lazy mode by defaultA cleaner version based on: #636
Test result:
Combined with the lazy loading option, disabling fastnode, rollback takes
1.8son one of our testnet archive node(337G), previously it was several hours.