-
Notifications
You must be signed in to change notification settings - Fork 43
Adds isolated instance mode description #5136
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
base: latest
Are you sure you want to change the base?
Conversation
The ```isolated:true``` option moves the instance to RO mode In this mode, various debugging & maintanance operations can be performed Fixes #4632
Fixes language and syntax
The isolated mode moves the instance to the read-only state, in which: | ||
|
||
* iproto stops listening for new connections | ||
* iproto drops all the current connections | ||
* The instance is disconnected from all the replication upstreams | ||
* Other replicaset members exclude the isolated instance from the replication upstreams |
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.
This wording seems a bit misleading: 'read-only state, which stops iproto and disconnects replication'. In fact, the isolated state/mode sets the read-only state, stops iproto and so on.
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.
Fixed
* The instance is disconnected from all the replication upstreams | ||
* Other replicaset members exclude the isolated instance from the replication upstreams | ||
|
||
Once the mode is enabled, any request trying to change persistent data will fail with the ``ER_READONLY`` error. |
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.
A remote request likely just fails, because we drop iproto connections. Not sure that we should add a note regarding ER_READONLY
.
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.
Fixed
i-002: {} | ||
i-003: {} | ||
i-004: | ||
isolated: true |
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.
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.
fixed
doc/admin/troubleshoot.rst
Outdated
.. NOTE:: | ||
|
||
To avoid brain split between two masters, one of the instances may be put in the :ref:`isolated mode <_configuration_reference_isolated_mode>`. |
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.
It gives a false impression that the isolated mode somehow helps to avoid split-brain, but it means that we should detect is somehow faster than tarantool itself. It seems strange.
Here we can fight with consequences of split-brain to some extent. At least, isolate the broken instance from client requests using the config option.
Let's discuss how to better express it.
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.
updated
isolated:true
option moves the instance to RO modeFixes config: isolated mode for an instance #4632