47 lines
2.1 KiB
Plaintext
47 lines
2.1 KiB
Plaintext
[float]
|
|
[[breaking_80_node_changes]]
|
|
=== Node changes
|
|
|
|
//NOTE: The notable-breaking-changes tagged regions are re-used in the
|
|
//Installation and Upgrade Guide
|
|
//tag::notable-breaking-changes[]
|
|
|
|
// end::notable-breaking-changes[]
|
|
|
|
[float]
|
|
==== Removal of `node.max_local_storage_nodes` setting
|
|
|
|
The `node.max_local_storage_nodes` setting was deprecated in 7.x and
|
|
has been removed in 8.0. Nodes should be run on separate data paths
|
|
to ensure that each node is consistently assigned to the same data path.
|
|
|
|
[float]
|
|
==== Change of data folder layout
|
|
|
|
Each node's data is now stored directly in the data directory set by the
|
|
`path.data` setting, rather than in `${path.data}/nodes/0`, because the removal
|
|
of the `node.max_local_storage_nodes` setting means that nodes may no longer
|
|
share a data path. At startup, Elasticsearch will automatically migrate the data
|
|
path to the new layout. This automatic migration will not proceed if the data
|
|
path contains data for more than one node. You should move to a configuration in
|
|
which each node has its own data path before upgrading.
|
|
|
|
If you try to upgrade a configuration in which there is data for more than one
|
|
node in a data path then the automatic migration will fail and Elasticsearch
|
|
will refuse to start. To resolve this you will need to perform the migration
|
|
manually. The data for the extra nodes are stored in folders named
|
|
`${path.data}/nodes/1`, `${path.data}/nodes/2` and so on, and you should move
|
|
each of these folders to an appropriate location and then configure the
|
|
corresponding node to use this location for its data path. If your nodes each
|
|
have more than one data path in their `path.data` settings then you should move
|
|
all the corresponding subfolders in parallel. Each node uses the same subfolder
|
|
(e.g. `nodes/2`) across all its data paths.
|
|
|
|
[float]
|
|
==== Rejection of ancient closed indices
|
|
|
|
In earlier versions a node would start up even if it had data from indices
|
|
created in a version before the previous major version, as long as those
|
|
indices were closed. {es} now ensures that it is compatible with every index,
|
|
open or closed, at startup time.
|