honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/docs/reference/migration/migrate_7_0/indices.asciidoc

47 lines
2.3 KiB
Plaintext
Raw Normal View History

Disallow : in cluster and index/alias names (#26247) We use `:` for cross-cluster search (eg `cluster:index`), therefore, we should not allow the ambiguity when allowing cluster or index names. Relates to #23892
2017-08-17 16:57:26 -04:00
[[breaking_70_indices_changes]]
=== Indices changes
==== `:` is no longer allowed in index name
Due to cross-cluster search using `:` to separate a cluster and index name,
index names may no longer contain `:`.
Forbid negative values for index.unassigned.node_left.delayed_timeout (#26828) Change delayed_timeout to be a positiveTimeSetting, and add note that this is a breaking change
2017-09-29 09:44:43 -04:00
==== `index.unassigned.node_left.delayed_timeout` may no longer be negative
Negative values were interpreted as zero in earlier versions but are no
longer accepted.
Don't refresh on `_flush` `_force_merge` and `_upgrade` (#27000) Today all these API calls have a sideeffect of making documents visible to search requests. While this is sometimes desired it's an unnecessary sideeffect and now that we have an internal (engine-private) index reader (#26972) we artificially add a refresh call for bwc. This change removes this sideeffect in 7.0.
2017-10-16 04:16:35 -04:00
==== `_flush` and `_force_merge` will no longer refresh
In previous versions issuing a `_flush` or `_force_merge` (with `flush=true`)
had the undocumented side-effect of refreshing the index which made new documents
visible to searches and non-realtime GET operations. From now on these operations
don't have this side-effect anymore. To make documents visible an explicit `_refresh`
call is needed unless the index is refreshed by the internal scheduler.
Add limits for ngram and shingle settings (#27211) (#27318) Relates to #25887
2017-11-08 10:12:57 -05:00
==== Limit to the difference between max_size and min_size in NGramTokenFilter and NGramTokenizer
To safeguard against creating too many index terms, the difference between `max_ngram` and
`min_ngram` in `NGramTokenFilter` and `NGramTokenizer` has been limited to 1. This default
limit can be changed with the index setting `index.max_ngram_diff`. Note that if the limit is
exceeded a error is thrown only for new indices. For existing pre-7.0 indices, a deprecation
warning is logged.
==== Limit to the difference between max_size and min_size in ShingleTokenFilter
To safeguard against creating too many tokens, the difference between `max_shingle_size` and
`min_shingle_size` in `ShingleTokenFilter` has been limited to 3. This default
limit can be changed with the index setting `index.max_shingle_diff`. Note that if the limit is
exceeded a error is thrown only for new indices. For existing pre-7.0 indices, a deprecation
Automatically prepare indices for splitting (#27451) Today we require users to prepare their indices for split operations. Yet, we can do this automatically when an index is created which would make the split feature a much more appealing option since it doesn't have any 3rd party prerequisites anymore. This change automatically sets the number of routinng shards such that an index is guaranteed to be able to split once into twice as many shards. The number of routing shards is scaled towards the default shard limit per index such that indices with a smaller amount of shards can be split more often than larger ones. For instance an index with 1 or 2 shards can be split 10x (until it approaches 1024 shards) while an index created with 128 shards can only be split 3x by a factor of 2. Please note this is just a default value and users can still prepare their indices with `index.number_of_routing_shards` for custom splitting. NOTE: this change has an impact on the document distribution since we are changing the hash space. Documents are still uniformly distributed across all shards but since we are artificually changing the number of buckets in the consistent hashign space document might be hashed into different shards compared to previous versions. This is a 7.0 only change.
2017-11-23 03:48:54 -05:00
warning is logged.
==== Document distribution changes
Indices created with version `7.0.0` onwards will have an automatic `index.number_of_routing_shards`
value set. This might change how documents are distributed across shards depending on how many
shards the index has. In order to maintain the exact same distribution as a pre `7.0.0` index, the
`index.number_of_routing_shards` must be set to the `index.number_of_shards` at index creation time.
Note: if the number of routing shards equals the number of shards `_split` operations are not supported.