Add steps to migrate from a legacy kibana index #82161
Conversation
rudolf
added
Team:Core
|
Pinging @elastic/kibana-platform (Team:Platform) |
| 1. Mark the legacy index as read-only and wait for all in-flight operations to drain (requires https://github.com/elastic/elasticsearch/pull/58094). This prevents any further writes from outdated nodes. Assuming this API is similar to the existing `/<index>/_close` API, we expect to receive `"acknowledged" : true` and `"shards_acknowledged" : true`. If all shards don’t acknowledge within the timeout, retry the operation until it succeeds. | ||
| 2. Clone the legacy index into a new index which has writes enabled. Use a fixed index name i.e `.kibana_pre6.5.0_001` or `.kibana_task_manager_pre7.4.0_001`. `POST /.kibana/_clone/.kibana_pre6.5.0_001?wait_for_active_shards=all {"settings": {"index.blocks.write": false}}`. Ignore errors if the clone already exists. Ignore errors if the legacy source doesn't exist. | ||
| 3. Wait for the cloning to complete `GET /_cluster/health/.kibana_pre6.5.0_001?wait_for_status=green&timeout=60s` If cloning doesn’t complete within the 60s timeout, log a warning for visibility and poll again. | ||
| 4. Apply the `convertToAlias` script if defined `POST /.kibana_pre6.5.0_001/_update_by_query?conflicts=proceed {"script": {...}}`. The `convertToAlias` script will have to be idempotent, preferably setting `ctx.op="noop"` on subsequent runs to avoid unecessary writes. |
There was a problem hiding this comment.
This will require some work to the task manager convertToAliasScript
rudolf
added
release_note:skip
| @@ -212,39 +212,59 @@ Note: | |||
| If none of the aliases exists, this is a new Elasticsearch cluster and no | |||
| migrations are necessary. Create the `.kibana_7.10.0_001` index with the | |||
| following aliases: `.kibana_current` and `.kibana_7.10.0`. | |||
| 2. If `.kibana_current` and `.kibana_7.10.0` both exists and are pointing to the same index this version's migration has already been completed. | |||
| 2. If the source is a < v6.5 `.kibana` index or < 7.4 `.kibana_task_manager` | |||
There was a problem hiding this comment.
nit: If the user upgraded from < 5.6 to 6.0, they will have a .kibana alias pointing at a .kibana-6 index. However, if they have a fresh deploy < 6.5, then they'll have a bare .kibana index. I don't think this has any concrete impact on the algorithm that you're proposing; however, it makes the naming of the index a bit imprecise: .kibana_pre6.5.0_001
Source: https://www.elastic.co/guide/en/kibana/6.0/migrating-6.0-index.html contains the manual steps which are equivalent to what the Upgrade Assistant did.
P.S. I'm primarily relaying the information that @tylersmalley gave me on Slack because he's a wealth of knowledge about old upgrades ❤️
kibanamachine
added
the
backport missing
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
1 similar comment
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
kibanamachine
removed
the
backport missing
rudolf
added
backport missing
kibanamachine
removed
the
backport missing
Summary
Adds additional steps for migrating from a legacy index. The existing legacy reindex algorithm wasn't idempotent. These changes have the following implications:
Unlike the existing migration algorithm, we won't create an alias that points
to the reindexed target. So after migrating a v6
.kibanawe'll have.kibana_pre6.5.0_001but there will be no.kibanaalias or index. This isbecause we have no way to ensure that when we try to delete the old
index, we don't accidently delete the newly cloned index with the same
alias. Should this happen we'd completely loose the data in the legacy index.
This algorithm shares a limitation with our existing migration algorithm
(since v7.4). When the task manager index gets reindexed a reindex script is
applied. Because we delete the original task manager index there is no way to
rollback a failed task manager migration without a snapshot.
Checklist
Delete any items that are not applicable to this PR.
For maintainers