-
Notifications
You must be signed in to change notification settings - Fork 782
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
Remove pubkey cache file #1787
Comments
From Discord:
Reportedly occurred after OOM. |
I'm not sure it's trivial to rebuild the cache from any database. We don't just need all the keys in the head state, we need to go and find the state with the largest |
I just mean that we store a table in the DB that is exactly the same as the current pubkey cache, so we get DB writes rather than hand-rolled ones. A user on Discord reported corruption after a power outage:
|
I am experiencing the same problem after a power outage.
Questions:
|
I've sent you the file on Discord, but just in case you check GH first:
Yeah :\
An earlier backup might work if you get lucky, but a backup from another node is more reliable. |
Another instance on Discord today after power failure:
|
## Issue Addressed Closes #1787 ## Proposed Changes * Abstract the `ValidatorPubkeyCache` over a "backing" which is either a file (legacy), or the database. * Implement a migration from schema v2 to schema v3, whereby the contents of the cache file are copied to the DB, and then the file is deleted. The next release to include this change must be a minor version bump, and we will need to warn users of the inability to downgrade (this is our first DB schema change since mainnet genesis). * Move the schema migration code from the `store` crate into the `beacon_chain` crate so that it can access the datadir and the `ValidatorPubkeyCache`, etc. It gets injected back into the `store` via a closure (similar to what we do in fork choice).
## Issue Addressed Closes #1787 ## Proposed Changes * Abstract the `ValidatorPubkeyCache` over a "backing" which is either a file (legacy), or the database. * Implement a migration from schema v2 to schema v3, whereby the contents of the cache file are copied to the DB, and then the file is deleted. The next release to include this change must be a minor version bump, and we will need to warn users of the inability to downgrade (this is our first DB schema change since mainnet genesis). * Move the schema migration code from the `store` crate into the `beacon_chain` crate so that it can access the datadir and the `ValidatorPubkeyCache`, etc. It gets injected back into the `store` via a closure (similar to what we do in fork choice).
Description
The pubkey cache file is unnecessary when we have a perfectly good database available. I think it would save complexity and reduce the likelihood of error if it were removed and rolled into the database. Its separate handling has been the source of bugs, e.g. #1680
This also links into the locking timeout issue #1096.
The text was updated successfully, but these errors were encountered: