Elasticsearch-->Get Started-->Exploring Your Cluster

Version

直接对localhost:9200发出一个get请求

{
"name": "WqeJVip",
"cluster_name": "elasticsearch",
"cluster_uuid": "BcCJ0AuOTCyD6RYSBCEACA",
"version": {
"number": "6.6.1",
"build_flavor": "default",
"build_type": "zip",
"build_hash": "1fd8f69",
"build_date": "2019-02-13T17:10:04.160291Z",
"build_snapshot": false,
"lucene_version": "7.6.0",
"minimum_wire_compatibility_version": "5.6.0",
"minimum_index_compatibility_version": "5.0.0"
},
"tagline": "You Know, for Search"
}

 Setting

GET /_all/_settings HTTP/1.1
Host: localhost:9200
cache-control: no-cache
Postman-Token: 4aa0826c-faaa-48ab-a7f2-569442d0e79d

Cluster Health(A cluster is a collection of one or more nodes (servers) )

https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-cluster-health.html

C:WINDOWSsystem32>curl -X GET "localhost:9200/_cat/health?v"

结果如下，列是对齐的

epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1551867679 10:21:19  elasticsearch green           1         1      0   0    0    0        0             0                  -                100.0%

We can see that our cluster named "elasticsearch" is up with a green status.

Whenever we ask for the cluster health, we either get green, yellow, or red.

• Green - everything is good (cluster is fully functional)
• Yellow - all data is available but some replicas are not yet allocated (cluster is fully functional)
• Red - some data is not available for whatever reason (cluster is partially functional)

Note: When a cluster is red, it will continue to serve search requests from the available shards but you will likely need to fix it ASAP since there are unassigned shards.

Also from the above response, we can see a total of 1 node and that we have 0 shards since we have no data in it yet.

Note that since we are using the default cluster name (elasticsearch) and since Elasticsearch uses unicast network discovery by default to find other nodes on the same machine, it is possible that you could accidentally start up more than one node on your computer and have them all join a single cluster. In this scenario, you may see more than 1 node in the above response.

We can also get a list of nodes in our cluster as follows:

curl -X GET "localhost:9200/_cat/nodes?v"

ip        heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
127.0.0.1           18          62  28                          mdi       *      WqeJVip

Here, we can see our one node named "WqeJVip", which is the single node that is currently in our cluster.

 List All Indices

https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-list-indices.html

Now let’s take a peek at our indices:

curl -X GET "localhost:9200/_cat/indices?v"

And the response:

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size

Which simply means we have no indices yet in the cluster.

Create an Index

Now let’s create an index named "customer" and then list all the indexes again:

curl -X PUT "localhost:9200/customer?pretty"
curl -X GET "localhost:9200/_cat/indices?v"

HTTP/1.1 200 OK
Warning: 299 Elasticsearch-6.6.1-1fd8f69 "the default number of shards will change from [5] to [1] in 7.0.0; if you wish to continue using the default of [5] shards, you must manage this on the create index request or with an index template" "Mon, 18 Mar 2019 07:17:24 GMT"
content-type: application/json; charset=UTF-8
content-length: 84

{
"acknowledged" : true,
"shards_acknowledged" : true,
"index" : "customer"
}

The first command creates the index named "customer" using the PUT verb. We simply append pretty to the end of the call to tell it to pretty-print the JSON response (if any).

And the response:

health status index    uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   customer p6H8gEOdQAWBuSN2HDEjZA   5   1          0            0      1.2kb          1.2kb

The results of the second command tells us that we now have 1 index named customer and it has 5 primary shards and 1 replica (the defaults) and it contains 0 documents in it.

You might also notice that the customer index has a yellow health tagged to it. Recall from our previous discussion that yellow means that some replicas are not (yet) allocated. The reason this happens for this index is because Elasticsearch by default created one replica for this index. Since we only have one node running at the moment, that one replica cannot yet be allocated (for high availability) until a later point in time when another node joins the cluster. Once that replica gets allocated onto a second node, the health status for this index will turn to green.

Index and Query a Document

Let’s now put something into our customer index.

We’ll index a simple customer document into the customer index, with an ID of 1 as follows:

语法是 /index/_doc/id?pretty

PUT /customer/_doc/1?pretty
{
  "name": "John Doe"
}

遇到如下错误

{
"error" : {
"root_cause" : [
{
"type" : "cluster_block_exception",
"reason" : "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"
}
],
"type" : "cluster_block_exception",
"reason" : "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"
},
"status" : 403
}

问题解决之后，Elasticsearch cluster_block_exception

{
"_index" : "customer",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 0,
"_primary_term" : 2
}

From the above, we can see that a new customer document was successfully created inside the customer index. The document also has an internal id of 1 which we specified at index time.

It is important to note that Elasticsearch does not require you to explicitly显式地 create an index first before you can index documents into it. In the previous example, Elasticsearch will automatically create the customer index if it didn’t already exist beforehand.

Let’s now retrieve that document that we just indexed:

查询语法是 /index/_doc/id

GET /customer/_doc/1?pretty

And the response:

{
"_index" : "customer",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"_seq_no" : 0,
"_primary_term" : 2,
"found" : true,
"_source" : {
"name" : "John Doe"
}
}

Nothing out of the ordinary here other than a field, found, stating that we found a document with the requested ID 1 and another field, _source, which returns the full JSON document that we indexed from the previous step

Delete an Index

Now let’s delete the index that we just created and then list all the indexes again:

DELETE /customer?pretty
GET /_cat/indices?v

 

And the response:

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size

Which means that the index was deleted successfully and we are now back to where we started with nothing in our cluster.

Before we move on, let’s take a closer look again at some of the API commands that we have learned so far:

PUT /customer
PUT /customer/_doc/1
{
  "name": "John Doe"
}
GET /customer/_doc/1
DELETE /customer

 

If we study the above commands carefully, we can actually see a pattern of how we access data in Elasticsearch. That pattern can be summarized as follows:

<HTTP Verb> /<Index>/<Type>/<ID>

This REST access pattern is so pervasive普遍的 throughout all the API commands that if you can simply remember it, you will have a good head start at mastering Elasticsearch.