-
Notifications
You must be signed in to change notification settings - Fork 38
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
meta: fix upgrade to v3 #3048
meta: fix upgrade to v3 #3048
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3048 +/- ##
==========================================
+ Coverage 22.41% 22.43% +0.01%
==========================================
Files 791 791
Lines 58405 58381 -24
==========================================
+ Hits 13093 13096 +3
+ Misses 44416 44386 -30
- Partials 896 899 +3 ☔ View full report in Codecov by Sentry. |
For now, the only idea of how this could happen is restarting before migration is completed. |
But it all happens in a single transaction, either it's in or it's out. |
Fixes error shard/control.go:17 metabase failure, switching mode {"shard_id": "XxhmeQZZRSQfDGfiCYo9mB", "stage": "init", "mode": "READ_ONLY", "error": "migrating from 2 to 3 version failed, consider database resync: graveyard value with unexpected 72 length"} Signed-off-by: Roman Khimov <[email protected]>
da61ece
to
d34687c
Compare
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.
Hm, this explains a lot.
The key is 2addebf, yes. And that was present in the original patch as well. |
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.
@roman-khimov d34687c worth changelog to me, very admin-friendly change
I don't think it changes anything for the admin, especially now. This would be a (really minor) issue for us when migration from 3 to 4 is to appear, old structure can handle this too, but it's somewhat less convenient. |
Use complete DB reload to get closer to how node works in real life, it usually opens an existing DB and any open/init code can affect the result. Signed-off-by: Roman Khimov <[email protected]>
It wasn't updated previously leading to attempts to upgrade the DB on every start. Which then leads to error shard/control.go:17 metabase failure, switching mode {"shard_id": "XxhmeQZZRSQfDGfiCYo9mB", "stage": "init", "mode": "READ_ONLY", "error": "migrating from 2 to 3 version failed, consider database resync: graveyard value with unexpected 72 length"} on 0.44.0/0.44.1. Signed-off-by: Roman Khimov <[email protected]>
Reuse getVersion(). Signed-off-by: Roman Khimov <[email protected]>
Too short and generic name, shadowed already in updateVersion(). Signed-off-by: Roman Khimov <[email protected]>
This code was added in 6f243a2 and it looks like it was mainly to ensure some correct processing of metabases that have no version info stored at all (they could've had some valid data still). Nowadays all correct metabases have version data stored, if it's not there it's either a broken or a new (more likely) DB. Also, doing any things like that in Open() is suspicious, it shouldn't care much about the state, that's what Init() is for. Notice that ErrOutdatedVersion for unknown versions is handled above. Signed-off-by: Roman Khimov <[email protected]>
Each handler works with a particular version, each updates to the next version, chaining them we're getting to the current, that's it. Signed-off-by: Roman Khimov <[email protected]>
d34687c
to
d16d757
Compare
No description provided.