mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-06-30 02:13:33 -04:00
0df12a8580
Today we fail the node at startup if it contains an index that is too old to be compatible with the current version, unless that index is closed. If the index is closed then the node will start up and this puts us into a bad state: the index cannot be opened and must be reindexed using an earlier version, but we offer no way to get that index into a node running an earlier version so that it can be reindexed. Downgrading the node in-place is decidedly unsupported and cannot be expected to work since the node already started up and upgraded the rest of its metadata. Since #41731 we actively reject downgrades to versions ≥ v7.2.0 too. This commit prevents the node from starting in the presence of any too-old indices (closed or not). In particular, it does not write any upgraded metadata in this situation, increasing the chances an in-place downgrade might be successful. We still actively reject the downgrade using #41731, because we wrote the node metadata file before checking the index metadata, but at least there is a way to override this check. Relates #21830, #44230
46 lines
2.1 KiB
Text
46 lines
2.1 KiB
Text
[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.
|