honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/docs/reference/release-notes/7.9.asciidoc

40 lines
1.8 KiB
Plaintext
Raw Normal View History

Scripting: Deprecate general cache settings (#55753) (#58283) Backport: ef543b0
2020-06-18 13:54:23 -04:00
[[release-notes-7.9.0]]
== {es} version 7.9.0
Also see <<breaking-changes-7.9,Breaking changes in 7.9>>.
[[breaking-7.9.0]]
[float]
=== Breaking changes
Script Cache::
[DOCS] Updates pull and issue release attributes (#58348)
2020-06-18 15:38:49 -04:00
* Script cache size and rate limiting are per-context {es-pull}55753[#55753] (issue: {es-issue}50152[#50152])
Docs - Added field capabilities breaking change (#58509)
2020-06-24 13:39:01 -04:00
Field capabilities API::
* Constant_keyword fields are now described by their family type `keyword` instead of `constant_keyword` {es-pull}58483[#58483] (issue: {es-issue}53175[#53175])
Account for recovery throttling when restoring snapshot (#58658) (#58811) Restoring from a snapshot (which is a particular form of recovery) does not currently take recovery throttling into account (i.e. the `indices.recovery.max_bytes_per_sec` setting). While restores are subject to their own throttling (repository setting `max_restore_bytes_per_sec`), this repository setting does not allow for values to be configured differently on a per-node basis. As restores are very similar in nature to peer recoveries (streaming bytes to the node), it makes sense to configure throttling in a single place. The `max_restore_bytes_per_sec` setting is also changed to default to unlimited now, whereas previously it was set to `40mb`, which is the current default of `indices.recovery.max_bytes_per_sec`). This means that no behavioral change will be observed by clusters where the recovery and restore settings were not adapted. Relates https://github.com/elastic/elasticsearch/issues/57023 Co-authored-by: James Rodewig <james.rodewig@elastic.co>
2020-07-01 06:19:29 -04:00
Snapshot restore throttling::
* Restoring from a snapshot (which is a particular form of recovery) is now
properly taking recovery throttling into account (i.e. the
`indices.recovery.max_bytes_per_sec` setting).
The `max_restore_bytes_per_sec` setting is also now defaulting to
unlimited, whereas previously it was set to `40mb`, which is the
default that's used for `indices.recovery.max_bytes_per_sec`. This means
that no behavioral change will be observed by clusters where the recovery
and restore settings had not been adapted from the defaults. {es-pull}58658[#58658]
Increase default write queue size (#59464) This commit increases the default write queue size to 10000. This is to allow a greater number of pending indexing requests. This work is safe as we have added additional memory limits. Relates to #59263.
2020-07-14 12:35:25 -04:00
Thread pool write queue size::
* The WRITE thread pool default queue size (`thread_pool.write.size`) has been
increased from 200 to 10000. A small queue size (200) caused issues when users
wanted to send small indexing requests with a high client count. Additional
memory-oriented back pressure has been introduced with the
`indexing_pressure.memory.limit` setting. This setting configures a limit to
the number of bytes allowed to be consumed by outstanding indexing requests.
{es-issue}59263[#59263]
Default gateway.auto_import_dangling_indices to false (#59302) Backport of #58898. Part of #48366. Now that there is a dedicated API for dangling indices, the auto-import behaviour can default to off. Also add a note to the breaking changes for 7.9.0.
2020-07-15 12:10:42 -04:00
Dangling indices::
* Automatically importing dangling indices is now deprecated, disabled by
default, and will be removed in {es} 8.0. See the
<<deprecate_auto_import_dangling_indices,migration notes>>.
{es-pull}58176[#58176] {es-pull}58898[#58898] (issue: {es-issue}48366[#48366])