Elasticsearch notes (3)

This is the 13th day of my participation in The August Wenwen Challenge.

Description of elasticearch.yml file configuration

Cluster Cluster configuration

Node Node Configuration

Paths Configuration

Memory Memory configuration

Network and HTTP configuration

Geteway gateway

Recovery Cluster Recovery → Cluster HA configuration

Discovery cluster Discovery → Cluster Discovery using the main cluster Discovery configuration

Cache Cache → Configuration about Cache

Translog configuration → Log configuration for transaction operations

ES operation (part 1)

Index related operations (including mapping and setting)

Index health checks (minor) can be done with ESheader

# get_cluster /health:/ / 192.168.123.64:9200 / _cluster/healthReturn content ### {# node name"cluster_name": "es-application"The most important piece of response information is the status field. The status can be one of three values #green: all master and replica shards are allocated. Your cluster is 100% available. # YELLOW: All master shards have been sharded, but at least one copy is missing. No data is lost, so search results remain intact. However, your high availability is somewhat weakened. If more shards disappear, you lose data. Think of yellow as a warning that needs to be investigated in time. At least one master shard (and all its copies) is missing. This means you are missing data: a search returns only partial data, and a write request assigned to the shard returns an exception."status": "green"# Green/YELLOW /red status is a great way to get an overview of your cluster and see what's going on right now. The remaining metrics give you an overview of the cluster's state:"timed_out": false, #number_of_nodes and number_of_data_nodes the names are completely self-descriptive."number_of_nodes": 1."number_of_data_nodes": 1, # indicates the number of master shards in your cluster. This is a summary value that covers all indexes."active_primary_shards": 0, # is the total value of _ all _ shards covering all indexes, that is, including replica shards"active_shards": 0, # displays the number of shards currently migrating from one node to another. Normally it should be 0, but this value increases when Elasticsearch finds that the cluster is not very balanced. For example, a new node is added, or a node is taken offline."relocating_shards": 0, # is the number of shards just created. For example, when you create your first index, the shard will be in an 'initializing' state for a short time. This is usually a temporary event, and sharding should not stay in the 'initializing' state for long. You may also see 'initializing' sharding when the node is first restarted: when the sharding is loaded from disk, it starts from the 'initializing' state"initializing_shards": 0, # is a shard that already exists in the cluster state, but is not actually found in the cluster. Usually the source of an unallocated shard is an unallocated copy. For example, an index with 5 shards and 1 replica will have 5 unallocated replica shards on a single-node cluster. If your cluster is in 'red' state, it will hold unallocated shards for a long time (due to lack of primary shards)"unassigned_shards": 0."delayed_unassigned_shards": 0."number_of_pending_tasks": 0."number_of_in_flight_fetch": 0."task_max_waiting_in_queue_millis": 0."active_shards_percent_as_number": 100.0
}
Copy the code

Create indexes

#PUT /{index name} (custom)/ / 192.168.123.64:9200 / index_jacquesh
{
    "settings": {
        "index": {
            "number_of_shards": "2", # number of master shards"number_of_replicas": "0"}} # return {"acknowledged": true."shards_acknowledged": true."index": "index_jacquesh"} # create successfullyCopy the code

View index

# GET _cat/indices? vCopy the code

return

Remove the index

#DELETE /{index name} (custom)/ / 192.168.123.64:9200 / index_jacquesh1# returns {"acknowledged": true} # delete succeededCopy the code