-
Notifications
You must be signed in to change notification settings - Fork 632
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
Is being dependent on the Check method enough for detecting boltdb corruption? #174
Comments
Tx.Check is diagnostic method that checks consistency in given point of time using some set of rules.
Using public API operations database should not get corrupted. But due to a bug, hardware issue, cosmic rays such corruption might happen. |
BTW: #225 is expanding the Checks to cover also a logical errors (unexpected key order). |
I am currently dealing with a corrupt database file in production, where iterating the keys in one bucket give wrong data, and reading another bucket never finishes and eats up all RAM until the process is killed. I feel forced to do such a consistency check after opening the database to mitigate such issues. |
@benma Is it possible for you to share the corrupt database? |
I found two databases from around that time, but I don't know anymore if these are the ones that ate up all the RAM or if they had different issues such as panics: |
Pages in [3655, 3715] were somehow reset. All zero values in these pages. FYI. #520 |
If I call the Check method when I read from boltdb the first time, is that enough to ensure boltdb is not corrupted? Or do I need to call it periodically within my process that is reading from boltdb? Is there anything else that needs to be done?
https://godoc.org/go.etcd.io/bbolt#Tx.Check
The text was updated successfully, but these errors were encountered: