原英文版地址: https://www.elastic.co/guide/en/elasticsearch/reference/7.7/breaking-changes-7.7.html, 原文档版权归 www.elastic.co 所有
本地英文版地址: ../en/breaking-changes-7.7.html
重要: 此版本不会发布额外的bug修复或文档更新。最新信息请参考 当前版本文档。
Elasticsearch Guide [7.7] » Breaking changes » Breaking changes in 7.7
« Breaking changes Breaking changes in 7.6 »

Breaking changes in 7.7edit

This section discusses the changes that you need to be aware of when migrating your application to Elasticsearch 7.7.

See also 7.7版本的新特性 and Release notes.

Security changesedit

The xpack.security.transport.ssl.enabled setting will be required to configure xpack.security.transport.ssl settings.

Details
Configuring any SSL settings for xpack.security.transport.ssl without also configuring xpack.security.transport.ssl.enabled generates warnings in the deprecation log. In 8.0, this configuration will result in errors.

Impact
To avoid deprecation warnings, either:

  • Explicitly set xpack.security.transport.ssl.enabled as false
  • Discontinue use of other xpack.security.transport.ssl settings

If you want to enable SSL, follow the instructions to encrypt communications between nodes. As part of this configuration, explicitly set xpack.security.transport.ssl.enabled as true.

For example:

xpack.security.transport.ssl.enabled: true 
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

or false.
The xpack.security.http.ssl.enabled setting will be required to configure xpack.security.http.ssl settings.

Details
Configuring any SSL settings for xpack.security.http.ssl without also configuring xpack.security.http.ssl.enabled generates warnings in the deprecation log. In 8.0, this configuration will result in errors.

Impact
To avoid deprecation warnings, either:

  • Explicitly set xpack.security.http.ssl.enabled as false
  • Discontinue use of other xpack.security.http.ssl settings

If you want to enable SSL, follow the instructions to encrypt HTTP client communications for Elasticsearch. As part of this configuration, explicitly set xpack.security.http.ssl.enabled as true.

For example:

xpack.security.http.ssl.enabled: true 
xpack.security.http.ssl.certificate: elasticsearch.crt
xpack.security.http.ssl.key: elasticsearch.key
xpack.security.http.ssl.certificate_authorities: [ "corporate-ca.crt" ]

or false.
A xpack.security.transport.ssl certificate and key will be required to enable SSL for the transport interface.

Details
Enabling SSL for the transport interface without also configuring a certificate and key through use of the xpack.security.transport.ssl.keystore.path setting or the xpack.security.transport.ssl.certificate and xpack.security.transport.ssl.key settings generates warnings in the deprecation log. In 8.0, this configuration will result in errors.

Impact
If xpack.security.transport.ssl.enabled is set to true, provide a certificate and key using the xpack.security.transport.ssl.keystore.path setting or the xpack.security.transport.ssl.certificate and xpack.security.transport.ssl.key settings. If a certificate and key is not provided, Elasticsearch will generate warnings in the deprecation log.

A xpack.security.http.ssl certificate and key will be required to enable SSL for the HTTP layer.

Details
Enabling SSL for the HTTP layer without also configuring a certificate and key through use of the xpack.security.http.ssl.keystore.path setting or the xpack.security.http.ssl.certificate and xpack.security.http.ssl.key settings generates warnings in the deprecation log. In 8.0, this configuration will result in errors.

Impact
If xpack.security.http.ssl.enabled is set to true, provide a certificate and key using the xpack.security.http.ssl.keystore.path setting or the xpack.security.http.ssl.certificate and xpack.security.http.ssl.key settings. If a certificate and key is not provided, Elasticsearch will generate warnings in the deprecation log.

Indices deprecationsedit

Translog retention settings are deprecated.edit

The index.translog.retention.age and index.translog.retention.size index settings are now deprecated. These settings have been ignored since 7.4 in favor of soft deletes.

To avoid deprecation warnings, discontinue use of the settings.

Logging changesedit

Loggers under org.elasticsearch.action now log at INFO level by defaultedit

The default log level for most loggers is INFO, but in earlier versions loggers in the org.elasticsearch.action.* hierarchy emitted log messages at DEBUG level by default. This sometimes resulted in a good deal of unnecessary log noise. From 7.7 onwards the default log level for logger in this hierarchy is now INFO, in line with most other loggers. If needed, you can recover the pre-7.7 default behaviour by adjusting your logging.

Mapping changesedit

Validation for dynamic templatesedit

So far misconfiguration of dynamic templates have been discovered when indexing a document with an unmapped field only. In Elasticsearch 8.0 and later versions, dynamic mappings have stricter validation, done at mapping update time. Invalid updates, such as using incorrect analyzer settings or unknown field types, fail. For indices created in Elasticsearch 7.7 and later version, the update succeeds but emits a warning.

Settings changesedit

thread_pool.listener.size and thread_pool.listener.queue_size have been deprecatededit

The listener thread pool is no longer used internally by Elasticsearch. Therefore, these settings have been deprecated. You can safely remove these settings from the configuration of your nodes.

cluster.remote.connect is deprecated in favor of node.remote_cluster_clientedit

Previously the setting cluster.remote.connect was used to configure whether or not the local node is capable of acting as a remote cluster client in cross-cluster search and cross-cluster replication. This setting is deprecated in favor of node.remote_cluster_client serves the same purpose and identifies the local node as having the remote_cluster_client role.

Authentication realm order will be a required config in version 8.0.0.edit

The order config will be required in version 8.0.0 for authentication realm configuration of any type. If the order config is missing for a realm, the node will fail to start.

Authentication realm order uniqueness will be enforced in version 8.0.0.edit

The order config of authentication realms must be unique in version 8.0.0. If you configure more than one realm of any type with the same order, the node will fail to start.

Deprecation of insecure monitoring password settingedit

The auth.password setting for the monitoring HTTP exporter has been deprecated and will be removed in version 8.0.0. Please use the auth.secure_password setting instead.

Settings used to defer cluster recovery pending a certain number of master nodes are deprecated.edit

The following cluster settings are now deprecated:

  • gateway.expected_nodes
  • gateway.expected_master_nodes
  • gateway.recover_after_nodes
  • gateway.recover_after_master_nodes

It is safe to recover the cluster as soon as a majority of master-eligible nodes have joined. There is no benefit in waiting for any additional master-eligible nodes to start.

To avoid deprecation warnings, discontinue use of the deprecated settings. If needed, use gateway.expected_data_nodes or gateway.recover_after_data_nodes to defer cluster recovery pending a certain number of data nodes.

Search changesedit

Consistent rounding of range queries on date_range fieldsedit

range queries on date_range field currently can have slightly differently boundaries than their equivalent query on a pure date field. This can e.g. happen when using date math or dates that don’t specify up to the last millisecond. While queries on date field round up to the latest millisecond for gt and lte boundaries, the same queries on date_range fields didn’t do this. The behavior is now the same for both field types like documented in Date math and rounding.

Pipeline aggregation validation errorsedit

The pipeline aggregation validation has been moved to the coordinating node. Those errors that used to return HTTP 500s/Internal Server Errors now return 400/Bad Request and we now return a list of validation errors rather than the first one we encounter.

Highlighters changesedit

Ignored keyword values are no longer highlightededit

If a keyword value was ignored during indexing because of its length (ignore_above parameter was applied), Elasticsearch doesn’t attempt to highlight it anymore, which means no highlights are produced for ignored values.

« Breaking changes Breaking changes in 7.6 »