update-settings.asciidoc 3.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118
  1. [[cluster-update-settings]]
  2. == Cluster Update Settings
  3. Use this API to review and change cluster-wide settings.
  4. To review cluster settings:
  5. [source,js]
  6. --------------------------------------------------
  7. GET /_cluster/settings
  8. --------------------------------------------------
  9. // CONSOLE
  10. Updates to settings can be persistent, meaning they apply across restarts, or transient, where they don't
  11. survive a full cluster restart. Here is an example of a persistent update:
  12. [source,js]
  13. --------------------------------------------------
  14. PUT /_cluster/settings
  15. {
  16. "persistent" : {
  17. "indices.recovery.max_bytes_per_sec" : "50mb"
  18. }
  19. }
  20. --------------------------------------------------
  21. // CONSOLE
  22. This update is transient:
  23. [source,js]
  24. --------------------------------------------------
  25. PUT /_cluster/settings?flat_settings=true
  26. {
  27. "transient" : {
  28. "indices.recovery.max_bytes_per_sec" : "20mb"
  29. }
  30. }
  31. --------------------------------------------------
  32. // CONSOLE
  33. The response to an update returns the changed setting, as in this response to the transient example:
  34. [source,js]
  35. --------------------------------------------------
  36. {
  37. ...
  38. "persistent" : { },
  39. "transient" : {
  40. "indices.recovery.max_bytes_per_sec" : "20mb"
  41. }
  42. }
  43. --------------------------------------------------
  44. // TESTRESPONSE[s/\.\.\./"acknowledged": true,/]
  45. You can reset persistent or transient settings by assigning a
  46. `null` value. If a transient setting is reset, the first one of these values that is defined is applied:
  47. * the persistent setting
  48. * the setting in the configuration file
  49. * the default value.
  50. This example resets a setting:
  51. [source,js]
  52. --------------------------------------------------
  53. PUT /_cluster/settings
  54. {
  55. "transient" : {
  56. "indices.recovery.max_bytes_per_sec" : null
  57. }
  58. }
  59. --------------------------------------------------
  60. // CONSOLE
  61. The response does not include settings that have been reset:
  62. [source,js]
  63. --------------------------------------------------
  64. {
  65. ...
  66. "persistent" : {},
  67. "transient" : {}
  68. }
  69. --------------------------------------------------
  70. // TESTRESPONSE[s/\.\.\./"acknowledged": true,/]
  71. You can also reset settings using wildcards. For example, to reset
  72. all dynamic `indices.recovery` settings:
  73. [source,js]
  74. --------------------------------------------------
  75. PUT /_cluster/settings
  76. {
  77. "transient" : {
  78. "indices.recovery.*" : null
  79. }
  80. }
  81. --------------------------------------------------
  82. // CONSOLE
  83. [float]
  84. === Order of Precedence
  85. The order of precedence for cluster settings is:
  86. 1. transient cluster settings
  87. 2. persistent cluster settings
  88. 3. settings in the `elasticsearch.yml` configuration file.
  89. It's best to set all cluster-wide settings with the `settings` API and use the
  90. `elasticsearch.yml` file only for local configurations. This way you can be sure that
  91. the setting is the same on all nodes. If, on the other hand, you define different
  92. settings on different nodes by accident using the configuration file, it is very
  93. difficult to notice these discrepancies.
  94. You can find the list of settings that you can dynamically update in <<modules,Modules>>.