85 lines
3.0 KiB
Plaintext
85 lines
3.0 KiB
Plaintext
[[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.
|
|
-- |