mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-06 21:18:31 +00:00
cd304c4def
If a node exceeds the flood-stage disk watermark then we add a block to all of its indices to prevent further writes as a last-ditch attempt to prevent the node completely exhausting its disk space. However today this block remains in place until manually removed, and this block is a source of confusion for users who current have ample disk space and did not even realise they nearly ran out at some point in the past. This commit changes our behaviour to automatically remove this block when a node drops below the high watermark again. The expectation is that the high watermark is some distance below the flood-stage watermark and therefore the disk space problem is truly resolved. Fixes #39334
113 lines
4.5 KiB
Plaintext
113 lines
4.5 KiB
Plaintext
[[breaking-changes-7.4]]
|
|
== Breaking changes in 7.4
|
|
++++
|
|
<titleabbrev>7.4</titleabbrev>
|
|
++++
|
|
|
|
This section discusses the changes that you need to be aware of when migrating
|
|
your application to Elasticsearch 7.4.
|
|
|
|
See also <<release-highlights>> and <<es-release-notes>>.
|
|
|
|
coming[7.4.0]
|
|
|
|
//NOTE: The notable-breaking-changes tagged regions are re-used in the
|
|
//Installation and Upgrade Guide
|
|
|
|
//tag::notable-breaking-changes[]
|
|
|
|
// end::notable-breaking-changes[]
|
|
|
|
[[breaking_74_plugin_changes]]
|
|
=== Plugins changes
|
|
|
|
[float]
|
|
==== TokenizerFactory changes
|
|
|
|
TokenizerFactory now has a `name()` method that must be implemented. Most
|
|
plugin-provided TokenizerFactory implementations will extend `AbstractTokenizerFactory`,
|
|
which now takes a `name` parameter in its constructor.
|
|
|
|
[float]
|
|
[[breaking_74_search_changes]]
|
|
=== Search Changes
|
|
|
|
[float]
|
|
==== Forbid empty doc values in vector functions
|
|
If a document doesn't have a value for a vector field (dense_vector
|
|
or sparse_vector) on which a vector function is executed, an error will
|
|
be thrown.
|
|
|
|
[float]
|
|
[[breaking_74_snapshots_changes]]
|
|
=== Snapshot and Restore changes
|
|
|
|
[float]
|
|
==== The S3 repository plugin uses the DNS style access pattern by default
|
|
|
|
Starting in version 7.4 the `repository-s3` plugin does not use the
|
|
now-deprecated path-style access pattern by default. In versions 7.0, 7.1, 7.2
|
|
and 7.3 the `repository-s3` plugin always used the path-style access pattern.
|
|
This is a breaking change for deployments that only support path-style access
|
|
but which are recognized as supporting DNS-style access by the AWS SDK. If your
|
|
deployment only supports path-style access and is affected by this change then
|
|
you must configure the S3 client setting `path_style_access` to `true`. This
|
|
breaking change was made necessary by
|
|
https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/[AWS's
|
|
announcement] that the path-style access pattern is deprecated and will be
|
|
unsupported on buckets created after September 30th 2020.
|
|
|
|
[float]
|
|
[[breaking_80_http_changes]]
|
|
=== HTTP changes
|
|
|
|
[float]
|
|
==== Changes to Encoding Plus Signs in URLs
|
|
|
|
Starting in version 7.4, a `+` in a URL will be encoded as `%2B` by all REST API functionality. Prior versions handled a `+` as a single space.
|
|
If your application requires handling `+` as a single space you can return to the old behaviour by setting the system property
|
|
`es.rest.url_plus_as_space` to `true`. Note that this behaviour is deprecated and setting this system property to `true` will cease
|
|
to be supported in version 8.
|
|
|
|
[float]
|
|
[[breaking_74_cluster_changes]]
|
|
=== Cluster changes
|
|
|
|
[float]
|
|
==== Rerouting after starting a shard runs at lower priority
|
|
|
|
After starting each shard the elected master node must perform a reroute to
|
|
search for other shards that could be allocated. In particular, when creating
|
|
an index it is this task that allocates the replicas once the primaries have
|
|
started. In versions prior to 7.4 this task runs at priority `URGENT`, but
|
|
starting in version 7.4 its priority is reduced to `NORMAL`. In a
|
|
well-configured cluster this reduces the amount of work the master must do, but
|
|
means that a cluster with a master that is overloaded with other tasks at
|
|
`HIGH` or `URGENT` priority may take longer to allocate all replicas.
|
|
|
|
Additionally, before 7.4 the `GET
|
|
_cluster_health?wait_for_no_initializing_shards` and `GET
|
|
_cluster/health?wait_for_no_relocating_shards` APIs would return only once all
|
|
pending reroutes have completed too, but starting in version 7.4 if you want to
|
|
wait for the rerouting process to completely finish you should add the
|
|
`wait_for_events=languid` query parameter when calling these APIs.
|
|
|
|
[float]
|
|
[[breaking_74_allocation_changes]]
|
|
=== Allocation changes
|
|
|
|
[float]
|
|
==== Auto-release of read-only-allow-delete block
|
|
|
|
If a node exceeds the flood-stage disk watermark then we add a block to all of
|
|
its indices to prevent further writes as a last-ditch attempt to prevent the
|
|
node completely exhausting its disk space. In earlier versions this block would
|
|
remain in place until manually removed, causing confusion for users who
|
|
currently have ample disk space and are not aware that they nearly ran out at
|
|
some point in the past. From 7.4 onwards the block is automatically removed
|
|
when a node drops below the high watermark again, with the expectation that the
|
|
high watermark is some distance below the flood-stage watermark and therefore
|
|
the disk space problem is truly resolved. This behaviour can be disabled by
|
|
setting the system property `es.disk.auto_release_flood_stage_block` to
|
|
`false`.
|