2019-01-31 09:40:06 -05:00
|
|
|
[float]
|
|
|
|
|
[[breaking_70_node_changes]]
|
|
|
|
|
=== Node start up
|
|
|
|
|
|
2019-04-08 21:54:29 -04:00
|
|
|
//NOTE: The notable-breaking-changes tagged regions are re-used in the
|
|
|
|
|
//Installation and Upgrade Guide
|
|
|
|
|
|
|
|
|
|
//tag::notable-breaking-changes[]
|
|
|
|
|
|
|
|
|
|
// end::notable-breaking-changes[]
|
|
|
|
|
|
2019-01-31 09:40:06 -05:00
|
|
|
[float]
|
|
|
|
|
==== Nodes with left-behind data or metadata refuse to start
|
|
|
|
|
Repurposing an existing node by changing node.master or node.data to false can leave lingering on-disk metadata and
|
|
|
|
|
data around, which will not be accessible by the node's new role. Beside storing non-accessible data, this can lead
|
|
|
|
|
to situations where dangling indices are imported even though the node might not be able to host any shards, leading
|
|
|
|
|
to a red cluster health. To avoid this,
|
|
|
|
|
|
|
|
|
|
* nodes with on-disk shard data and node.data set to false will refuse to start
|
|
|
|
|
* nodes with on-disk index/shard data and both node.master and node.data set to false will refuse to start
|
|
|
|
|
|
|
|
|
|
Beware that such role changes done prior to the 7.0 upgrade could prevent node start up in 7.0.
|
