Previously, primary shards were only assigned if a quorum of shard copies were
found (configurable using
index.recovery.initial_shards, now deprecated). In
case where a primary had only a single replica, quorum was defined to be a
single shard. This meant that any shard copy of an index with replication
factor 1 could become primary, even it was a stale copy of the data on disk.
This is now fixed thanks to shard allocation IDs.
Allocation IDs assign unique identifiers to shard copies. This allows the cluster to differentiate between multiple copies of the same data and track which shards have been active so that, after a cluster restart, only shard copies containing the most recent data can become primaries.
By using allocation IDs instead of version numbers to identify shard copies for primary shard allocation, the former versioning scheme has become obsolete. This is reflected in the Indices Shard Stores API.
allocation_id field replaces the former
version field in the result
of the Indices Shard Stores command. This field is available for all shard
copies that have been either created with the current version of Elasticsearch
or have been active in a cluster running a current version of Elasticsearch.
For legacy shard copies that have not been active in a current version of
legacy_version field is available instead (equivalent to
The reroute command
allocate has been split into two distinct commands
allocate_empty_primary. This was done as we
introduced a new
allocate_stale_primary command. The new
command corresponds to the old
allocate command with
allow_primary set to
false. The new
allocate_empty_primary command corresponds to the old
allocate command with
allow_primary set to true.
Elasticsearch no longer supports plugins registering custom allocation commands. It was unused and hopefully unneeded.
The behavior of
index.shared_filesystem.recover_on_any_node: true has been
changed. Previously, in the case where no shard copies could be found, an
arbitrary node was chosen by potentially ignoring allocation deciders. Now, we
take balancing into account but don’t assign the shard if the allocation
deciders are not satisfied.
The behavior has also changed in the case where shard copies can be found. Previously, a node not holding the shard copy was chosen if none of the nodes holding shard copies were satisfying the allocation deciders. Now, the shard will be assigned to a node having a shard copy, even if none of the nodes holding a shard copy satisfy the allocation deciders.