-
Notifications
You must be signed in to change notification settings - Fork 264
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
feat: speed up rollback command #636
Conversation
d9f40d1
to
9c1abd8
Compare
@@ -605,6 +586,11 @@ func (ndb *nodeDB) deleteNodesFrom(version int64, hash []byte) error { | |||
return err | |||
} | |||
|
|||
if node.version < version { |
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.
Like
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the trade off here?
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.
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.
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.
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 created
|
Co-authored-by: yihuang <huang@crypto.com> Co-authored-by: Marko Baricevic <marbar3778@yahoo.com>
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.8s
on one of our testnet archive node(337G), previously it was several hours.