-
Notifications
You must be signed in to change notification settings - Fork 29
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
Storages with OperationError state should be excluded from vshard config #1411
Comments
We've recently discussed a similar problem in the context of the It sounds like you need an "automatic disable" feature, but it may be dangerous. |
Yes, but seems we anyway should provide such behaviour... As the first step we could provide it under an option. Or probably storage shouldn't accept requests (I don't know how is it possible). |
Router will check the replies from a storage and in case of error will redirect the request automatically. Although, for all OperationErrors appeared at a higher level there should be a different approach. |
The tarantool/vshard#298 is fixed, need to verify the problem is resolved. |
It's not resolved. Because vshard doesn't know anything about cartridge. Steps to fix an issue:
|
In case of OperationError (config was unsuccessfully applied on storage) we shouldn't perform request to such storage. After this feature was implemented in vshard (tarantool/vshard#298) we could just disable vshard storage on such instances. For this purpose simple trigger on_apply_config was implemented. Closes #1411
In case of OperationError (config was unsuccessfully applied on storage) we shouldn't perform request to such storage. After this feature was implemented in vshard (tarantool/vshard#298) we could just disable vshard storage on such instances. For this purpose simple trigger on_apply_config was implemented. Closes #1411
Related blockers |
In case of OperationError (config was unsuccessfully applied on storage) we shouldn't perform request to such storage. After this feature was implemented in vshard (tarantool/vshard#298) we could just disable vshard storage on such instances. For this purpose simple trigger on_apply_config was implemented. Closes #1411
In case of OperationError (config was unsuccessfully applied on storage) we shouldn't perform request to such storage. After this feature was implemented in vshard (tarantool/vshard#298) we could just disable vshard storage on such instances. For this purpose simple trigger on_apply_config was implemented. Closes #1411
In case of OperationError (config was unsuccessfully applied on storage) we shouldn't perform request to such storage. After this feature was implemented in vshard (tarantool/vshard#298) we could just disable vshard storage on such instances. For this purpose simple trigger on_apply_config was implemented. Closes #1411
In case of OperationError (config was unsuccessfully applied on storage) we shouldn't perform request to such storage. After this feature was implemented in vshard (tarantool/vshard#298) we could just disable vshard storage on such instances. For this purpose simple trigger on_apply_config was implemented. Closes #1411
In case of OperationError (config was unsuccessfully applied on storage) we shouldn't perform request to such storage. After this feature was implemented in vshard (tarantool/vshard#298) we could just disable vshard storage on such instances. For this purpose simple trigger on_apply_config was implemented. Closes #1411
In case of OperationError (config was unsuccessfully applied on storage) we shouldn't perform request to such storage. After this feature was implemented in vshard (tarantool/vshard#298) we could just disable vshard storage on such instances. For this purpose simple trigger on_apply_config was implemented. Closes #1411
In case of OperationError (config was unsuccessfully applied on storage) we shouldn't perform request to such storage. After this feature was implemented in vshard (tarantool/vshard#298) we could just disable vshard storage on such instances. For this purpose simple trigger on_apply_config was implemented. Closes #1411
Since vshard doesn't know anything about cartridge state machine we could have a case when
vshard makes requests to instance with OperationError state. It looks wrong and unclear for customers.
The text was updated successfully, but these errors were encountered: