misc.asciidoc 4.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112
  1. [[misc-cluster]]
  2. === Miscellaneous cluster settings
  3. [[cluster-read-only]]
  4. ==== Metadata
  5. An entire cluster may be set to read-only with the following _dynamic_ setting:
  6. `cluster.blocks.read_only`::
  7. Make the whole cluster read only (indices do not accept write
  8. operations), metadata is not allowed to be modified (create or delete
  9. indices).
  10. `cluster.blocks.read_only_allow_delete`::
  11. Identical to `cluster.blocks.read_only` but allows to delete indices
  12. to free up resources.
  13. WARNING: Don't rely on this setting to prevent changes to your cluster. Any
  14. user with access to the <<cluster-update-settings,cluster-update-settings>>
  15. API can make the cluster read-write again.
  16. [[user-defined-data]]
  17. ==== User Defined Cluster Metadata
  18. User-defined metadata can be stored and retrieved using the Cluster Settings API.
  19. This can be used to store arbitrary, infrequently-changing data about the cluster
  20. without the need to create an index to store it. This data may be stored using
  21. any key prefixed with `cluster.metadata.`. For example, to store the email
  22. address of the administrator of a cluster under the key `cluster.metadata.administrator`,
  23. issue this request:
  24. [source,js]
  25. -------------------------------
  26. PUT /_cluster/settings
  27. {
  28. "persistent": {
  29. "cluster.metadata.administrator": "sysadmin@example.com"
  30. }
  31. }
  32. -------------------------------
  33. // CONSOLE
  34. IMPORTANT: User-defined cluster metadata is not intended to store sensitive or
  35. confidential information. Any information stored in user-defined cluster
  36. metadata will be viewable by anyone with access to the
  37. <<cluster-get-settings,Cluster Get Settings>> API, and is recorded in the
  38. {es} logs.
  39. [[cluster-max-tombstones]]
  40. ==== Index Tombstones
  41. The cluster state maintains index tombstones to explicitly denote indices that
  42. have been deleted. The number of tombstones maintained in the cluster state is
  43. controlled by the following property, which cannot be updated dynamically:
  44. `cluster.indices.tombstones.size`::
  45. Index tombstones prevent nodes that are not part of the cluster when a delete
  46. occurs from joining the cluster and reimporting the index as though the delete
  47. was never issued. To keep the cluster state from growing huge we only keep the
  48. last `cluster.indices.tombstones.size` deletes, which defaults to 500. You can
  49. increase it if you expect nodes to be absent from the cluster and miss more
  50. than 500 deletes. We think that is rare, thus the default. Tombstones don't take
  51. up much space, but we also think that a number like 50,000 is probably too big.
  52. [[cluster-logger]]
  53. ==== Logger
  54. The settings which control logging can be updated dynamically with the
  55. `logger.` prefix. For instance, to increase the logging level of the
  56. `indices.recovery` module to `DEBUG`, issue this request:
  57. [source,js]
  58. -------------------------------
  59. PUT /_cluster/settings
  60. {
  61. "transient": {
  62. "logger.org.elasticsearch.indices.recovery": "DEBUG"
  63. }
  64. }
  65. -------------------------------
  66. // CONSOLE
  67. [[persistent-tasks-allocation]]
  68. ==== Persistent Tasks Allocations
  69. Plugins can create a kind of tasks called persistent tasks. Those tasks are
  70. usually long-live tasks and are stored in the cluster state, allowing the
  71. tasks to be revived after a full cluster restart.
  72. Every time a persistent task is created, the master nodes takes care of
  73. assigning the task to a node of the cluster, and the assigned node will then
  74. pick up the task and execute it locally. The process of assigning persistent
  75. tasks to nodes is controlled by the following property, which can be updated
  76. dynamically:
  77. `cluster.persistent_tasks.allocation.enable`::
  78. +
  79. --
  80. Enable or disable allocation for persistent tasks:
  81. * `all` - (default) Allows persistent tasks to be assigned to nodes
  82. * `none` - No allocations are allowed for any type of persistent task
  83. This setting does not affect the persistent tasks that are already being executed.
  84. Only newly created persistent tasks, or tasks that must be reassigned (after a node
  85. left the cluster, for example), are impacted by this setting.
  86. --