disk_allocator.asciidoc 4.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103
  1. [[disk-allocator]]
  2. === Disk-based shard allocation
  3. Elasticsearch considers the available disk space on a node before deciding
  4. whether to allocate new shards to that node or to actively relocate shards away
  5. from that node.
  6. Below are the settings that can be configured in the `elasticsearch.yml` config
  7. file or updated dynamically on a live cluster with the
  8. <<cluster-update-settings,cluster-update-settings>> API:
  9. `cluster.routing.allocation.disk.threshold_enabled`::
  10. Defaults to `true`. Set to `false` to disable the disk allocation decider.
  11. `cluster.routing.allocation.disk.watermark.low`::
  12. Controls the low watermark for disk usage. It defaults to `85%`, meaning
  13. that Elasticsearch will not allocate shards to nodes that have more than
  14. 85% disk used. It can also be set to an absolute byte value (like `500mb`)
  15. to prevent Elasticsearch from allocating shards if less than the specified
  16. amount of space is available. This setting has no effect on the primary
  17. shards of newly-created indices or, specifically, any shards that have
  18. never previously been allocated.
  19. `cluster.routing.allocation.disk.watermark.high`::
  20. Controls the high watermark. It defaults to `90%`, meaning that
  21. Elasticsearch will attempt to relocate shards away from a node whose disk
  22. usage is above 90%. It can also be set to an absolute byte value (similarly
  23. to the low watermark) to relocate shards away from a node if it has less
  24. than the specified amount of free space. This setting affects the
  25. allocation of all shards, whether previously allocated or not.
  26. `cluster.routing.allocation.disk.watermark.flood_stage`::
  27. +
  28. --
  29. Controls the flood stage watermark. It defaults to 95%, meaning that
  30. Elasticsearch enforces a read-only index block
  31. (`index.blocks.read_only_allow_delete`) on every index that has one or more
  32. shards allocated on the node that has at least one disk exceeding the flood
  33. stage. This is a last resort to prevent nodes from running out of disk space.
  34. The index block must be released manually once there is enough disk space
  35. available to allow indexing operations to continue.
  36. NOTE: You can not mix the usage of percentage values and byte values within
  37. these settings. Either all are set to percentage values, or all are set to byte
  38. values. This is so that we can we validate that the settings are internally
  39. consistent (that is, the low disk threshold is not more than the high disk
  40. threshold, and the high disk threshold is not more than the flood stage
  41. threshold).
  42. An example of resetting the read-only index block on the `twitter` index:
  43. [source,js]
  44. --------------------------------------------------
  45. PUT /twitter/_settings
  46. {
  47. "index.blocks.read_only_allow_delete": null
  48. }
  49. --------------------------------------------------
  50. // CONSOLE
  51. // TEST[setup:twitter]
  52. --
  53. `cluster.info.update.interval`::
  54. How often Elasticsearch should check on disk usage for each node in the
  55. cluster. Defaults to `30s`.
  56. `cluster.routing.allocation.disk.include_relocations`::
  57. Defaults to +true+, which means that Elasticsearch will take into account
  58. shards that are currently being relocated to the target node when computing
  59. a node's disk usage. Taking relocating shards' sizes into account may,
  60. however, mean that the disk usage for a node is incorrectly estimated on
  61. the high side, since the relocation could be 90% complete and a recently
  62. retrieved disk usage would include the total size of the relocating shard
  63. as well as the space already used by the running relocation.
  64. NOTE: Percentage values refer to used disk space, while byte values refer to
  65. free disk space. This can be confusing, since it flips the meaning of high and
  66. low. For example, it makes sense to set the low watermark to 10gb and the high
  67. watermark to 5gb, but not the other way around.
  68. An example of updating the low watermark to at least 100 gigabytes free, a high
  69. watermark of at least 50 gigabytes free, and a flood stage watermark of 10
  70. gigabytes free, and updating the information about the cluster every minute:
  71. [source,js]
  72. --------------------------------------------------
  73. PUT _cluster/settings
  74. {
  75. "transient": {
  76. "cluster.routing.allocation.disk.watermark.low": "100gb",
  77. "cluster.routing.allocation.disk.watermark.high": "50gb",
  78. "cluster.routing.allocation.disk.watermark.flood_stage": "10gb",
  79. "cluster.info.update.interval": "1m"
  80. }
  81. }
  82. --------------------------------------------------
  83. // CONSOLE