-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Clarify that you cannot abort an upgrade #47342
Clarify that you cannot abort an upgrade #47342
Conversation
We do mention that rolling back an upgrade requires a restore from a snapshot, but it's hidden at the bottom of the "preparing to upgrade" instructions on a different page from the actual upgrade instructions. This commit duplicates the preparatory instructions onto the pages containing the actual upgrade instructions and rewords the point about rollbacks a bit.
Pinging @elastic/es-docs |
Pinging @elastic/es-distributed |
earlier versions cannot read. The only way to revert an incomplete upgrade is to | ||
completely delete the contents of the data path on each upgraded node. If this | ||
results in data loss then you will need to restore the lost data from a | ||
snapshot. |
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.
I am wondering if this remains open to interpretation. Maybe we should make a stronger statement that suggests you must discard the whole cluster if an upgrade fails.
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.
On reflection I think we have to say that. We don't test the node-by-node downgrade I suggested earlier, and it's definitely possible that the cluster state gets changed by a single upgraded node in a way that poisons the older nodes and e.g. prevents a second upgrade attempt.
I pushed 29d4ac8.
started to upgrade your cluster to version {version} you must complete the | ||
upgrade. As soon as the cluster contains nodes of version {version} it may make | ||
changes to its internal state that cannot be reverted. If you cannot complete | ||
the upgrade then you must deploy an empty cluster and restore its contents from |
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.
Perhaps you could start the section with this. Currently this feels hidden away in the bullet point about snapshots, whereas this is not only a property of that.
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.
Thanks for the suggestion, yes, it looks good there; see http://elasticsearch_47342.docs-preview.app.elstc.co/guide/en/elasticsearch/reference/master/restart-upgrade.html#restart-upgrade
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.
LGTM
We do mention that rolling back an upgrade requires a restore from a snapshot, but it's hidden at the bottom of the "preparing to upgrade" instructions on a different page from the actual upgrade instructions. This commit duplicates the preparatory instructions onto the pages containing the actual upgrade instructions and rewords the point about rollbacks a bit.
We do mention that rolling back an upgrade requires a restore from a snapshot, but it's hidden at the bottom of the "preparing to upgrade" instructions on a different page from the actual upgrade instructions. This commit duplicates the preparatory instructions onto the pages containing the actual upgrade instructions and rewords the point about rollbacks a bit.
We do mention that rolling back an upgrade requires a restore from a snapshot, but it's hidden at the bottom of the "preparing to upgrade" instructions on a different page from the actual upgrade instructions. This commit duplicates the preparatory instructions onto the pages containing the actual upgrade instructions and rewords the point about rollbacks a bit.
We do mention that rolling back an upgrade requires a restore from a snapshot, but it's hidden at the bottom of the "preparing to upgrade" instructions on a different page from the actual upgrade instructions. This commit duplicates the preparatory instructions onto the pages containing the actual upgrade instructions and rewords the point about rollbacks a bit.
We do mention that rolling back an upgrade requires a restore from a snapshot, but it's hidden at the bottom of the "preparing to upgrade" instructions on a different page from the actual upgrade instructions. This commit duplicates the preparatory instructions onto the pages containing the actual upgrade instructions and rewords the point about rollbacks a bit.
We do mention that rolling back an upgrade requires a restore from a snapshot, but it's hidden at the bottom of the "preparing to upgrade" instructions on a different page from the actual upgrade instructions. This commit duplicates the preparatory instructions onto the pages containing the actual upgrade instructions and rewords the point about rollbacks a bit.
We do mention that rolling back an upgrade requires a restore from a snapshot,
but it's hidden at the bottom of the "preparing to upgrade" instructions on a
different page from the actual upgrade instructions. This commit duplicates the
preparatory instructions onto the pages containing the actual upgrade
instructions and rewords the point about rollbacks a bit.