Updating indices.recovery.compress from to – How to solve related issues

Index and indexing in Elasticsearch - 3 min

Overview

In Elasticsearch, an index (plural: indices) contains a schema and can have one or more shards and replicas. An Elasticsearch index is divided into shards and each shard is an instance of a Lucene index.

Indices are used to store the documents in dedicated data structures corresponding to the data type of fields. For example, text fields are stored inside an inverted index whereas numeric and geo fields are stored inside BKD trees.

Examples

Create index

The following example is based on Elasticsearch version 5.x onwards. An index with two shards, each having one replica will be created with the name test_index1

PUT /test_index1?pretty
{
    "settings" : {
        "number_of_shards" : 2,
        "number_of_replicas" : 1
    },
    "mappings" : {
        "properties" : {
            "tags" : { "type" : "keyword" },
            "updated_at" : { "type" : "date" }
        }
    }
}

List indices

All the index names and their basic information can be retrieved using the following command:

GET _cat/indices?v

Index a document

Let’s add a document in the index with the command below:

PUT test_index1/_doc/1
{
  "tags": [
    "opster",
    "elasticsearch"
  ],
  "date": "01-01-2020"
}

Query an index

GET test_index1/_search
{
  "query": {
    "match_all": {}
  }
}

Query multiple indices

It is possible to search multiple indices with a single request. If it is a raw HTTP request, index names should be sent in comma-separated format, as shown in the example below, and in the case of a query via a programming language client such as python or Java, index names are to be sent in a list format.

GET test_index1,test_index2/_search

Delete indices

DELETE test_index1

Common problems

DELETE /*

action.destructive_requires_name: true

Overview

In Elasticsearch, recovery refers to the process of recovering an index or shard when something goes wrong. There are many ways to recover an index or shard, such as by re-indexing the data from a backup / failover cluster to the current one, or by restoring from an Elasticsearch snapshot. Alternatively, Elasticsearch performs recoveries automatically, such as when a node restarts or disconnects and connects again. There is an API to check the updated status of index / shard recoveries.

GET /<index>/_recoveryGET /_recovery

In summary, recovery can happen in the following scenarios:

• Node startup or failure (local store recovery)
• Replication of primary shards to replica shards
• Relocation of a shard to a different node in the same cluster
• Restoring a snapshot

Examples

Getting recovery information about several indices:

GET my_index1
GET my_index2/_recovery

Notes and good things to know

• When a node is disconnected from the cluster, all of its shards go to an unassigned state. After a certain amount of time, the shards will be allocated somewhere else on other nodes. This setting determines the number of concurrent shards per node that will be recovered.

PUT _cluster/settings{"transient":{"cluster.routing.allocation.node_concurrent_recoveries":3}}

• You can also control when to start recovery after a node disconnects. This is useful if the node just restarts, for example, because you may not want to initiate any recovery for such transient events.

PUT _all/_settings{"settings":{"index.unassigned.node_left.delayed_timeout":"6m"}}

• Elasticsearch limits the speed that is allocated to recovery in order to avoid overloading the cluster. This setting can be updated to make the recovery faster or slower, depending on your requirements.

PUT _cluster/settings{"transient":{"indices.recovery.max_bytes_per_sec":"100mb"}}

Settings in Elasticsearch

In Elasticsearch, you can configure cluster-level settings, node-level settings and index level settings. Here is a quick rundown of each level.

A. Cluster settings

These settings can either be:

1. Persistent, meaning they apply across restarts, or
2. Transient, meaning they won’t survive a full cluster restart.

If a transient setting is reset, the first one of these values that is defined is applied:

• The persistent setting
• The setting in the configuration file
• The default value

The order of precedence for cluster settings is:

1. Transient cluster settings
2. Persistent cluster settings
3. Settings in the elasticsearch.yml configuration file

Examples

An example of persistent cluster settings update:

PUT /_cluster/settings
{
    "persistent" : {
        "indices.recovery.max_bytes_per_sec" : "500mb"
    }
}

An example of a transient update:

PUT /_cluster/settings
{
    "transient" : {
        "indices.recovery.max_bytes_per_sec" : "40mb"
    }
}

B. Index settings

These are the settings that are applied to individual indices. There is an API to update index level settings.

Examples

The following API call will set the number of replica shards to 5 for my_index index.

PUT /my_index/_settings
{
    "index" : {
        "number_of_replicas" : 5    
     }
}

To revert a setting to the default value, use null.

PUT /my_index/_settings
{
    "index" : {
        "refresh_interval" : null
    }
}

C. Node settings

These settings apply to nodes. Nodes can fulfill different roles. These include the master, data, and coordination roles. Node settings are set through the elasticsearch.yml file for each node. 

Examples

Setting a node to be a data node (in the elasticsearch.yml file):

node.data: true

Disabling the ingest role for the node (which is enabled by default):

node.ingest: false

For production clusters, you will need to run each type of node on a dedicated machine with two or more instances of each, for HA (minimum three for master nodes).

Notes and good things to know

• Learning more about the cluster settings and index settings is important – it can spare you a lot of trouble. For example, if you are going to ingest huge amounts of data into an index and the number of replica shards is set to say, 5, the indexing process will be super slow because the data will be replicated at the same time it is indexed. What you can do to speed up indexing is to set the replica shards to 0 by updating the settings, and set it back to the original number when indexing is done, using the settings API.
• Another useful example of using cluster-level settings is when a node has just joined the cluster and the cluster is not assigning any shards to the node. Although shard allocation is enabled by default on all nodes, someone may have disabled shard allocation at some point (for example, in order to perform a rolling restart), and forgot to re-enable it later. To enable shard allocation, you can update the Cluster Settings API:

PUT /_cluster/settings{"transient":{"cluster.routing.allocation.enable":"all"}}

• It’s better to set cluster-wide settings with Settings API instead of with the elasticsearch.yml file and to use the file only for local changes. This will keep the same setting on all nodes. However, if you define different settings on different nodes by accident using the elasticsearch.yml configuration file, it is hard to notice these discrepancies.
• See also: Recovery