-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Migrations v2 docs #88820
Migrations v2 docs #88820
Conversation
Pinging @elastic/kibana-core (Team:Core) |
@elasticmachine merge upstream |
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.
From our testing, do we have any indication that there may be high load on ES from the parallel indexing from all the kibana nodes? If so, we may want to add a section about this, targeted at users that have high numbers of Kibana nodes.
It may even worth having a dedicated section about "Migrations with multiple Kibana nodes" that also mentions that all old nodes should be shutdown before starting the new nodes. Moving that detail out of the other sections into a section about that may help those users find that detail more effectively.
- Prior to 6.5.0, saved objects were stored directly in an index named `.kibana`. After upgrading to version 7.12+, {kib} will migrate this index into `.kibana_{kibana_version}_001` and set `.kibana` up as alias to this index. + | ||
- Prior to 7.4.0, task manager tasks were stored directly in an index name `.kibana_task_manager`. After upgrading to version 7.12+, {kib} will migrate this index into `.kibana_task_manager_{kibana_version}_001` and set `.kibana_task_manager` up as an index alias. + | ||
- Prior to 7.12.0, saved objects and task manager tasks were stored in `.kibana_N` and `.kibana_task_manager_N` where N is a number that's increased every time an upgrade migration was performed. After upgrading to version 7.12+, {kib} will migrate these indices into `.kibana_{kibana_version}_001` and `.kibana_task_manager_{kibana_version}_001` respectively. |
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.
Instead of the "Prior to X" language, I think it would be more clear if we said which versions each statement applied to, example:
- In Kibana versions 4.0.0 through 6.4.2, ...
- In Kibana versions 6.5.0 through 7.3.2, ...
- In Kibana versions 7.4.0 through 7.11.2, ...
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 tried to condense this into a table
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.
2. Identify any migration locks by comparing the output of `GET /_cat/aliases` and `GET /_cat/indices`. If e.g. `.kibana` is pointing to `.kibana_4` and there is a `.kibana_5` index, the `.kibana_5` index will act like a migration lock blocking further attempts. Be sure to check both the `.kibana` and `.kibana_task_manager` aliases and their indices. | ||
3. Remove any migration locks e.g. `DELETE /.kibana_5`. | ||
4. Start up all {kib} instances. | ||
If {kib} terminates unexpectedly while migrating a saved object index it will automatically attempt to perform the migration again once the process has restarted. If upgrade migrations fail repeatedly, follow the advice in (preventing migration failures)[preventing-migration-failures]. Unlike previous versions of {kib}, v7.12+ does not require deleting any indices to release a failed migration lock. Once the root cause for the migration failure has been addressed, {kib} will automatically retry the migration without any further intervention. |
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.
Maybe we should add a very clearly worded warning that in 7.12+ it is not recommended to delete any indices or aliases without first contacting Elastic Support.
We should also add a note that if you're dealing with a version prior to 7.12 to refer to the older docs. Not sure if our doc system supports linking to previous versions, but if so that'd be nice.
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 used stronger wording in 927b60a
Co-authored-by: Josh Dover <[email protected]>
I did some rudimentary testing by running migrations on 100k saved objects (much larger than "normal") and looking at the output of Migrations runtime with 100k objects:
Although at the end of the day, the impact of Kibana running migrations is most likely much less than the impact of users using Kibana and searching over much larger data sets than the saved objects index. If someone deploys 10 Kibana nodes it would be to support a large amount of concurrent users (or concurrent background work).
We do also mention it in the actual step-by-step upgrade instructions https://www.elastic.co/guide/en/kibana/current/upgrade-standard.html I feel like all the upgrade pages might benefit from an overhaul, there's a lot going on in them (with lots of warnings and callouts) which doesn't help users feel confident that they're doing things right. But I will add a dedicated multi-instance section and maybe just mention that for very large kibana deployments upgrade performance (and associated downtime) will be better if a single instance finished the upgrade before other instances were brought online. |
* Migrations v2 docs * Not all kibana distributions automatically restarted a killed process * Mention that we add a write block to the outdated index * Formating: collapse three notes into a single note with three bullet points * Update docs/setup/upgrade/upgrade-standard.asciidoc Co-authored-by: Josh Dover <[email protected]> * Add table of outdated / upgraded indices per version of Kibana * Review feedback: separate section for multi-instance upgrade migrations * Review feedback: link to saved objects management * Review feedback: stronger wording for not deleting any indices Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Josh Dover <[email protected]>
* Migrations v2 docs * Not all kibana distributions automatically restarted a killed process * Mention that we add a write block to the outdated index * Formating: collapse three notes into a single note with three bullet points * Update docs/setup/upgrade/upgrade-standard.asciidoc Co-authored-by: Josh Dover <[email protected]> * Add table of outdated / upgraded indices per version of Kibana * Review feedback: separate section for multi-instance upgrade migrations * Review feedback: link to saved objects management * Review feedback: stronger wording for not deleting any indices Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Josh Dover <[email protected]> Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Josh Dover <[email protected]>
Summary
Related: #75780
Closes: #86315
Checklist
Delete any items that are not applicable to this PR.
For maintainers