2019-07-04 06:23:27 -04:00
|
|
|
[[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.
|
|
|
|
|
|
2019-07-05 17:59:13 -04:00
|
|
|
[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.
|
|
|
|
|
|
2019-07-08 02:10:01 -04:00
|
|
|
[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.
|
2019-07-15 04:21:54 -04:00
|
|
|
|
|
|
|
|
[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
|
2019-07-18 09:10:40 -04:00
|
|
|
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.
|
2019-08-07 05:53:17 -04:00
|
|
|
|
|
|
|
|
[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`.
|
