[[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.


[[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.
--