Details
-
Task
-
Resolution: Unresolved
-
L3 - Default
-
None
-
None
-
None
-
Not defined
Description
It can be for a number of reasons that instance indices end up with custom shard settings. In self-managed environments, this could be because the custom requires more resources for instance heavy processes. Similarly, we might do that on a customer's behalf in SaaS.
When the number of instance index shards are configured in Optimize, this is applied globally to all indices and only at the point of index creation. This means that if a customer has a custom setting for a single index, this will be lost during migration.
Optimize should consider the current number of shards set per index during migration instead, to avoid the custom settings (and reindexes) needing to be applied every time.
Notes:
- This is challenging as we need to somehow detect whether custom settings have been applied
- If the shard number has been increased for an index, the new index should also use this setting
- If the shard number has been decreased for an index, the new index should also use this setting