-
Notifications
You must be signed in to change notification settings - Fork 1
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
improvement to zstor behaviors when some meta backends down #127
Comments
Hi @LeeSmet 0-stor_v2/zstor/src/actors/backends.rs Line 82 in b81264c
I can see the |
That's a leftover from old functionality. A long time ago there was functionality to automatically replace backends if they were full/failed. Since the feature was not used and caused a lot of complexity for maintenance, it was removed. The handler is an artifact that wasn't removed properly. If you want it can be removed. |
OK, i'll keep it for now as reference. |
tested on both master and #129 |
also fixed on #129 |
also fixed on #129. By re-creating the metastore when there is change in the meta zdb backends |
Based on #123 discussion, i want to do full check & improvements (if needed) regarding the behavior when some of the meta backends down
zstor monitor
must be started (discussion : Zstor doesn't start when connection to any Zdb times out #123, PR: fix(meta): metastore availability improvements #128)zstor monitor
automatically reconnect to that backend (fix(meta): refresh metastore if there is zdb up/down #129)zstor retrieve
must work if there are >= 2 available meta backends (Zstor doesn't start when connection to any Zdb times out #123 (comment))zstor store
must fail if one of the meta backend down (fix(meta): metastore availability improvements #128)zstor
config using SIGUSR1 must update the meta backends properly fix(meta): refresh metastore if there is zdb up/down #129ReplaceMetaStore
behavior fix(meta): refresh metastore if there is zdb up/down #129The text was updated successfully, but these errors were encountered: