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

Migrations v2 docs #88820

Merged
merged 13 commits into from
Jan 25, 2021
Merged

Migrations v2 docs #88820

merged 13 commits into from
Jan 25, 2021

Conversation

rudolf
Copy link
Contributor

@rudolf rudolf commented Jan 20, 2021

Summary

Related: #75780
Closes: #86315

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@rudolf rudolf added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v8.0.0 release_note:skip Skip the PR/issue when compiling release notes v7.12.0 project:ResilientSavedObjectMigrations Reduce Kibana upgrade failures by making saved object migrations more resilient labels Jan 20, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

@rudolf
Copy link
Contributor Author

rudolf commented Jan 21, 2021

@elasticmachine merge upstream

Copy link
Contributor

@joshdover joshdover left a 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.

Comment on lines 30 to 32
- 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.
Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Screenshot 2021-01-22 at 15 27 24

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.
Copy link
Contributor

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.

Copy link
Contributor Author

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

docs/setup/upgrade/upgrade-standard.asciidoc Outdated Show resolved Hide resolved
@rudolf
Copy link
Contributor Author

rudolf commented Jan 22, 2021

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.

I did some rudimentary testing by running migrations on 100k saved objects (much larger than "normal") and looking at the output of watch curl -s -X GET "elastic:changeme@localhost:9200/_cat/nodes?h=heap*\&v" -H 'Content-Type: application/json'. There isn't a notable impact on the current heap between 1 kibana node or 10 (the largest kibana deployment we know of). But the runtime of the migration doubles for 10 nodes, so there is a performance impact.

Migrations runtime with 100k objects:

Nodes Runtime
1 2.27 minutes
2 2.27 minutes
3 3.49 minutes
10 4.21 minutes

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

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.

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.

@rudolf rudolf merged commit eed9383 into elastic:master Jan 25, 2021
@rudolf rudolf deleted the migrations-v2-docs branch January 25, 2021 14:37
rudolf added a commit to rudolf/kibana that referenced this pull request Jan 26, 2021
* 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]>
rudolf added a commit that referenced this pull request Jan 26, 2021
* 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]>
@rudolf rudolf added the docs label Feb 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs project:ResilientSavedObjectMigrations Reduce Kibana upgrade failures by making saved object migrations more resilient release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.12.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

User-facing documentation for resilient saved object migrations
5 participants