2013-08-28 19:24:34 -04:00
|
|
|
[[cluster-update-settings]]
|
|
|
|
== Cluster Update Settings
|
|
|
|
|
2018-07-26 11:15:10 -04:00
|
|
|
Use this API to review and change cluster-wide settings.
|
|
|
|
|
|
|
|
To review cluster settings:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
GET /_cluster/settings
|
|
|
|
--------------------------------------------------
|
|
|
|
// CONSOLE
|
|
|
|
|
|
|
|
Updates to settings can be persistent, meaning they apply across restarts, or transient, where they don't
|
|
|
|
survive a full cluster restart. Here is an example of a persistent update:
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2017-02-10 17:57:43 -05:00
|
|
|
PUT /_cluster/settings
|
|
|
|
{
|
2013-08-28 19:24:34 -04:00
|
|
|
"persistent" : {
|
2017-02-10 17:57:43 -05:00
|
|
|
"indices.recovery.max_bytes_per_sec" : "50mb"
|
2015-06-22 17:49:45 -04:00
|
|
|
}
|
2017-02-10 17:57:43 -05:00
|
|
|
}
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
2017-02-10 17:57:43 -05:00
|
|
|
// CONSOLE
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2018-07-26 11:15:10 -04:00
|
|
|
This update is transient:
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2017-02-10 17:57:43 -05:00
|
|
|
PUT /_cluster/settings?flat_settings=true
|
|
|
|
{
|
2013-08-28 19:24:34 -04:00
|
|
|
"transient" : {
|
2017-02-10 17:57:43 -05:00
|
|
|
"indices.recovery.max_bytes_per_sec" : "20mb"
|
2015-06-22 17:49:45 -04:00
|
|
|
}
|
2017-02-10 17:57:43 -05:00
|
|
|
}
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
2017-02-10 17:57:43 -05:00
|
|
|
// CONSOLE
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2018-07-26 11:15:10 -04:00
|
|
|
The response to an update returns the changed setting, as in this response to the transient example:
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
{
|
2017-02-10 17:57:43 -05:00
|
|
|
...
|
|
|
|
"persistent" : { },
|
2013-08-28 19:24:34 -04:00
|
|
|
"transient" : {
|
2017-02-10 17:57:43 -05:00
|
|
|
"indices.recovery.max_bytes_per_sec" : "20mb"
|
2015-06-22 17:49:45 -04:00
|
|
|
}
|
2017-02-10 17:57:43 -05:00
|
|
|
}
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
2017-02-10 17:57:43 -05:00
|
|
|
// TESTRESPONSE[s/\.\.\./"acknowledged": true,/]
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2018-07-26 11:15:10 -04:00
|
|
|
You can reset persistent or transient settings by assigning a
|
|
|
|
`null` value. If a transient setting is reset, the first one of these values that is defined is applied:
|
|
|
|
|
|
|
|
* the persistent setting
|
|
|
|
* the setting in the configuration file
|
|
|
|
* the default value.
|
|
|
|
|
|
|
|
This example resets a setting:
|
2015-12-07 15:19:40 -05:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2017-02-10 17:57:43 -05:00
|
|
|
PUT /_cluster/settings
|
|
|
|
{
|
2015-12-07 15:19:40 -05:00
|
|
|
"transient" : {
|
2017-02-10 17:57:43 -05:00
|
|
|
"indices.recovery.max_bytes_per_sec" : null
|
2015-12-07 15:19:40 -05:00
|
|
|
}
|
2017-02-10 17:57:43 -05:00
|
|
|
}
|
2015-12-07 15:19:40 -05:00
|
|
|
--------------------------------------------------
|
2017-02-10 17:57:43 -05:00
|
|
|
// CONSOLE
|
2015-12-07 15:19:40 -05:00
|
|
|
|
2018-07-26 11:15:10 -04:00
|
|
|
The response does not include settings that have been reset:
|
2015-12-07 15:19:40 -05:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
{
|
2017-02-10 17:57:43 -05:00
|
|
|
...
|
2015-12-07 15:19:40 -05:00
|
|
|
"persistent" : {},
|
|
|
|
"transient" : {}
|
|
|
|
}
|
2015-12-09 06:24:40 -05:00
|
|
|
--------------------------------------------------
|
2017-02-10 17:57:43 -05:00
|
|
|
// TESTRESPONSE[s/\.\.\./"acknowledged": true,/]
|
2015-12-09 06:24:40 -05:00
|
|
|
|
2018-07-26 11:15:10 -04:00
|
|
|
You can also reset settings using wildcards. For example, to reset
|
|
|
|
all dynamic `indices.recovery` settings:
|
2015-12-09 06:24:40 -05:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2017-02-10 17:57:43 -05:00
|
|
|
PUT /_cluster/settings
|
|
|
|
{
|
2015-12-09 06:24:40 -05:00
|
|
|
"transient" : {
|
2017-02-10 17:57:43 -05:00
|
|
|
"indices.recovery.*" : null
|
2015-12-09 06:24:40 -05:00
|
|
|
}
|
2017-02-10 17:57:43 -05:00
|
|
|
}
|
2015-12-09 06:24:40 -05:00
|
|
|
--------------------------------------------------
|
2017-02-10 17:57:43 -05:00
|
|
|
// CONSOLE
|
2015-12-07 15:19:40 -05:00
|
|
|
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2015-11-05 08:40:06 -05:00
|
|
|
[float]
|
2018-07-26 11:15:10 -04:00
|
|
|
=== Order of Precedence
|
|
|
|
|
|
|
|
The order of precedence for cluster settings is:
|
2015-11-05 08:40:06 -05:00
|
|
|
|
2018-07-26 11:15:10 -04:00
|
|
|
1. transient cluster settings
|
|
|
|
2. persistent cluster settings
|
|
|
|
3. settings in the `elasticsearch.yml` configuration file.
|
2015-11-05 08:40:06 -05:00
|
|
|
|
2018-09-26 05:59:36 -04:00
|
|
|
It's best to set all cluster-wide settings with the `settings` API and use the
|
|
|
|
`elasticsearch.yml` file only for local configurations. This way you can be sure that
|
|
|
|
the setting is the same on all nodes. If, on the other hand, you define different
|
|
|
|
settings on different nodes by accident using the configuration file, it is very
|
|
|
|
difficult to notice these discrepancies.
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2018-07-26 11:15:10 -04:00
|
|
|
You can find the list of settings that you can dynamically update in <<modules,Modules>>.
|
2014-06-25 14:54:22 -04:00
|
|
|
|