123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112 |
- [[misc-cluster]]
- === Miscellaneous cluster settings
- [[cluster-read-only]]
- ==== Metadata
- An entire cluster may be set to read-only with the following _dynamic_ setting:
- `cluster.blocks.read_only`::
- Make the whole cluster read only (indices do not accept write
- operations), metadata is not allowed to be modified (create or delete
- indices).
- `cluster.blocks.read_only_allow_delete`::
- Identical to `cluster.blocks.read_only` but allows to delete indices
- to free up resources.
- WARNING: Don't rely on this setting to prevent changes to your cluster. Any
- user with access to the <<cluster-update-settings,cluster-update-settings>>
- API can make the cluster read-write again.
- [[user-defined-data]]
- ==== User Defined Cluster Metadata
- User-defined metadata can be stored and retrieved using the Cluster Settings API.
- This can be used to store arbitrary, infrequently-changing data about the cluster
- without the need to create an index to store it. This data may be stored using
- any key prefixed with `cluster.metadata.`. For example, to store the email
- address of the administrator of a cluster under the key `cluster.metadata.administrator`,
- issue this request:
- [source,js]
- -------------------------------
- PUT /_cluster/settings
- {
- "persistent": {
- "cluster.metadata.administrator": "sysadmin@example.com"
- }
- }
- -------------------------------
- // CONSOLE
- IMPORTANT: User-defined cluster metadata is not intended to store sensitive or
- confidential information. Any information stored in user-defined cluster
- metadata will be viewable by anyone with access to the
- <<cluster-get-settings,Cluster Get Settings>> API, and is recorded in the
- {es} logs.
- [[cluster-max-tombstones]]
- ==== Index Tombstones
- The cluster state maintains index tombstones to explicitly denote indices that
- have been deleted. The number of tombstones maintained in the cluster state is
- controlled by the following property, which cannot be updated dynamically:
- `cluster.indices.tombstones.size`::
- Index tombstones prevent nodes that are not part of the cluster when a delete
- occurs from joining the cluster and reimporting the index as though the delete
- was never issued. To keep the cluster state from growing huge we only keep the
- last `cluster.indices.tombstones.size` deletes, which defaults to 500. You can
- increase it if you expect nodes to be absent from the cluster and miss more
- than 500 deletes. We think that is rare, thus the default. Tombstones don't take
- up much space, but we also think that a number like 50,000 is probably too big.
- [[cluster-logger]]
- ==== Logger
- The settings which control logging can be updated dynamically with the
- `logger.` prefix. For instance, to increase the logging level of the
- `indices.recovery` module to `DEBUG`, issue this request:
- [source,js]
- -------------------------------
- PUT /_cluster/settings
- {
- "transient": {
- "logger.org.elasticsearch.indices.recovery": "DEBUG"
- }
- }
- -------------------------------
- // CONSOLE
- [[persistent-tasks-allocation]]
- ==== Persistent Tasks Allocations
- Plugins can create a kind of tasks called persistent tasks. Those tasks are
- usually long-live tasks and are stored in the cluster state, allowing the
- tasks to be revived after a full cluster restart.
- Every time a persistent task is created, the master nodes takes care of
- assigning the task to a node of the cluster, and the assigned node will then
- pick up the task and execute it locally. The process of assigning persistent
- tasks to nodes is controlled by the following property, which can be updated
- dynamically:
- `cluster.persistent_tasks.allocation.enable`::
- +
- --
- Enable or disable allocation for persistent tasks:
- * `all` - (default) Allows persistent tasks to be assigned to nodes
- * `none` - No allocations are allowed for any type of persistent task
- This setting does not affect the persistent tasks that are already being executed.
- Only newly created persistent tasks, or tasks that must be reassigned (after a node
- left the cluster, for example), are impacted by this setting.
- --
|