Skip to content
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

Closed
olegrok opened this issue May 11, 2021 · 6 comments · Fixed by #1692
Closed

Storages with OperationError state should be excluded from vshard config #1411

olegrok opened this issue May 11, 2021 · 6 comments · Fixed by #1692
Labels
Milestone

Comments

@olegrok
Copy link
Contributor

olegrok commented May 11, 2021

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.

@rosik
Copy link
Contributor

rosik commented May 11, 2021

We've recently discussed a similar problem in the context of the RecoveringSnapshot state.

It sounds like you need an "automatic disable" feature, but it may be dangerous.

@olegrok
Copy link
Contributor Author

olegrok commented May 11, 2021

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).

@sergos
Copy link

sergos commented Oct 8, 2021

Router will check the replies from a storage and in case of error will redirect the request automatically.
Details are tarantool/vshard#298

Although, for all OperationErrors appeared at a higher level there should be a different approach.

@sergos
Copy link

sergos commented Dec 21, 2021

The tarantool/vshard#298 is fixed, need to verify the problem is resolved.

@olegrok
Copy link
Contributor Author

olegrok commented Dec 22, 2021

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:

  • Release new vshard
  • Update vshard version in cartridge
  • Add vshard.storage.disable() when instance switches to the state to OperationError
  • Cover this case with test

olegrok added a commit that referenced this issue Jan 10, 2022
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
olegrok added a commit that referenced this issue Jan 10, 2022
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
@filonenko-mikhail
Copy link
Contributor

filonenko-mikhail commented Jan 13, 2022

olegrok added a commit that referenced this issue Feb 18, 2022
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
olegrok added a commit that referenced this issue Feb 19, 2022
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
@filonenko-mikhail filonenko-mikhail added this to the 2.8.0 milestone Apr 25, 2022
olegrok added a commit that referenced this issue May 24, 2022
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
olegrok added a commit that referenced this issue May 24, 2022
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
yngvar-antonsson pushed a commit that referenced this issue May 24, 2022
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
yngvar-antonsson pushed a commit that referenced this issue May 24, 2022
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
yngvar-antonsson pushed a commit that referenced this issue May 31, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants