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/cluster.asciidoc

28 lines
1.1 KiB
Plaintext
Raw Normal View History

[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
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_cluster_changes]]
=== Cluster changes
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
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
==== `:` is no longer allowed in cluster name
Due to cross-cluster search using `:` to separate a cluster and index name,
cluster names may no longer contain `:`.
Add v6.1 BWC layer for adding wait_for_active_shards to index open command This commit disables BWC tests while adding a v6.1 BWC layer for the PR #26682
2017-09-22 10:19:04 -04:00
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
remove _primary and _replica shard preferences (#26791) The shard preference _primary, _replica and its variants were useful for the asynchronous replication. However, with the current impl, they are no longer useful and should be removed. Closes #26335
2017-10-08 11:03:06 -04:00
==== New default for `wait_for_active_shards` parameter of the open index command
Add v6.1 BWC layer for adding wait_for_active_shards to index open command This commit disables BWC tests while adding a v6.1 BWC layer for the PR #26682
2017-09-22 10:19:04 -04:00
The default value for the `wait_for_active_shards` parameter of the open index API
is changed from 0 to 1, which means that the command will now by default wait for all
primary shards of the opened index to be allocated.
remove _primary and _replica shard preferences (#26791) The shard preference _primary, _replica and its variants were useful for the asynchronous replication. However, with the current impl, they are no longer useful and should be removed. Closes #26335
2017-10-08 11:03:06 -04:00
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
remove _primary and _replica shard preferences (#26791) The shard preference _primary, _replica and its variants were useful for the asynchronous replication. However, with the current impl, they are no longer useful and should be removed. Closes #26335
2017-10-08 11:03:06 -04:00
==== Shard preferences `_primary`, `_primary_first`, `_replica`, and `_replica_first` are removed
These shard preferences are removed in favour of the `_prefer_nodes` and `_only_nodes` preferences.
Add cluster-wide shard limit warnings (#34021) In a future major version, we will be introducing a soft limit on the number of shards in a cluster based on the number of nodes in the cluster. This limit will be configurable, and checked on operations which create or open shards and issue a warning if the operation would take the cluster over the limit. There is an option to enable strict enforcement of the limit, which turns the warnings into errors. In a future release, the option will be removed and strict enforcement will be the default (and only) behavior.
2018-10-23 18:35:10 -04:00
[float]
==== Cluster-wide shard soft limit
Clusters now have soft limits on the total number of open shards in the cluster
based on the number of nodes and the `cluster.max_shards_per_node` cluster
setting, to prevent accidental operations that would destabilize the cluster.
[Zen2] Best-effort cluster formation if unconfigured (#36215) In real deployments it is important that clusters are properly configured to avoid accidentally forming multiple independent clusters at cluster bootstrapping time. However we also expect to be able to unpack Elasticsearch and start up one or more nodes without any up-front configuration, and have them do their best to find each other and form a cluster after a few seconds. This change adds a delayed automatic bootstrapping process to nodes that start up with no relevant settings set to support the desired out-of-the-box experience without compromising safety in properly-configured deployments.
2018-12-07 07:47:09 -05:00
More information can be found in the <<misc-cluster,documentation for that setting>>.