mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-11 07:25:23 +00:00
As user-defined cluster metadata is accessible to anyone with access to get the cluster settings, stored in the logs, and likely to be tracked by monitoring solutions, it is useful to clarify in the documentation that it should not be used to store secret information.
112 lines
4.0 KiB
Plaintext
112 lines
4.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.
|
|
|
|
|
|
[[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.
|
|
-- |