Elasticsearch Cluster Operation Example detailed

Rest interface

Now that we have a functioning node (and cluster), the next step is to understand how to communicate with it. Fortunately, Elasticsearch provides a very comprehensive and powerful rest API that allows you to interact with your cluster using this REST API. Here are a few things you can do with this API:

1, check your cluster, node and index health status and various statistical information
2. Manage your clusters, nodes, index data, and meta data
3. CRUD (Create, read, update, delete) and search operations on your index
4. Perform advanced query operations such as paging, sorting, filtering, scripting (scripting), facet characterization (faceting), aggregation (aggregations), and many other operations
Cluster health (cluster health)

Let's start with a basic health check that we can use to view the status of our clusters. We use curl, and of course you can use this feature with any tool that you can use to create http/rest calls. Let's say we're still on the node where we started elasticsearch and open another shell window.

To check the cluster health, we will use the _cat API. What needs to be remembered is that the port of our node HTTP is 9200:
Curl ' localhost:9200/_cat/health?v '

The corresponding response is:
Epoch Timestamp cluster status node.total node.data shards pri relo init unassign
1394735289 14:28:09 elasticsearch Green 1 1 0 0 0 0 0

As you can see, the name of our cluster is "Elasticsearch", running normally, and the state is green.

When we look at the cluster state, we may get three states of green, yellow, or red. Green represents all normal (cluster full-featured); Yellow means that all data is available, but some replications are not allocated (clusters are fully functional), and red indicates that some data is not available for some reason. Note that even if the cluster state is red, the cluster is still partially available (it will still use the available fragmentation to respond to the search request), but you may need to fix it as soon as you have lost data.

From the response above, we can see a total of one node, because there is no data inside, we have 0 slices. Note that because we use the default cluster name (Elasticsearch) and because Elasticsearch uses network multicast (multicast) to discover other nodes by default, if you start multiple nodes in your network, you have already added them to the cluster. In this case, you may see multiple nodes in the response above.

We can also get a list of nodes in the section cluster:
Curl ' localhost:9200/_cat/nodes?v '

The corresponding response is:
Curl ' localhost:9200/_cat/nodes?v '
Host IP heap.percent ram.percent load node.role Master Name
MWUBUNTU1 127.0.1.1 8 4 0.00 D * New Goblin

Here, we can see the node called "New Goblin", the node that is the only node in our cluster.
List all indexes

Let's take a look at our index:
Curl ' localhost:9200/_cat/indices?v '

The corresponding response is:
Curl ' localhost:9200/_cat/indices?v '
Health Index PRI Rep docs.count docs.deleted Store.size pri.store.size

This result means that there are no indexes in our cluster.
Create an index

Now let's create an index called "customer" and then list all the indexes:
Curl-xput ' Localhost:9200/customer?pretty '
Curl ' localhost:9200/_cat/indices?v '

The first command creates an index called "customer" using put. We simply attach the pretty to the end of the call, so that it prints out the JSON response in beautiful form

The response is as follows:
Curl-xput ' Localhost:9200/customer?pretty '
{
' acknowledged ': true
}

Curl ' localhost:9200/_cat/indices?v '
Health Index PRI Rep docs.count docs.deleted Store.size pri.store.size
Yellow Customer 5 1 0 0 495b 495b

The result of the second command tells us that we now have an index called customer, and that it has 5 primary slices and 1 copies (all defaults), which contains 0 documents.

You may also have noticed that the customer index has a yellow health label. Looking back at our previous discussion, yellow means that certain replications are not (or have not) been assigned. This index is so because Elasticsearch creates a copy of the index by default. Since we have only one node running now, that copy cannot be allocated (for high availability) until another node joins the cluster. Once the copy is replicated on the second node, the healthy state of the node becomes green.
Index and query a document

Now let's put something in the customer index. The first thing to know is that in order to index a document, we have to tell Elasticsearch which type (type) The document will go to.

Let's index a simple customer document to the customer index, the "external" type, and the ID of this document is 1, as follows:
Curl-xput ' Localhost:9200/customer/external/1?pretty '-d '
{
"Name": "John Doe"
}'

The response is as follows:
Curl-xput ' Localhost:9200/customer/external/1?pretty '-d '
{
"Name": "John Doe"
}'
{
"_index": "Customer",
"_type": "External",
"_id": "1",
"_version": 1,
' Created ': true
}

From the response above, we can see that a new customer document was successfully created in the customer index and the external type. The document also has an internal ID 1, which we specified at the time of the index.

Note that when you want to index a document to an index, Elasticsearch does not force the index to be explicitly created. In the previous example, if the customer index does not exist, Elasticsearch will automatically create the index.

Now, let's take the document that we just indexed:
Curl-xget ' Localhost:9200/customer/external/1?pretty '

The response is as follows:
Curl-xget ' Localhost:9200/customer/external/1?pretty '
{
"_index": "Customer",
"_type": "External",
"_id": "1",
"_version": 1,
' Found ': true, ' _source ': {' name ': ' John Doe '}
}

There is nothing special except the found field--indicating that we found a document with ID 1 and the _source field, which returns the full JSON document we indexed in the previous step.
Delete a document

Now let's delete the index we just created and list all the indexes again:
Curl-xdelete ' Localhost:9200/customer?pretty '
Curl ' localhost:9200/_cat/indices?v '

The response is as follows:
Curl-xdelete ' Localhost:9200/customer?pretty '
{
' acknowledged ': true
}
Curl ' localhost:9200/_cat/indices?v '
Health Index PRI Rep docs.count docs.deleted Store.size pri.store.size

This indicates that we succeeded in deleting this index, and now we are back to the cluster hollow without all state.

Let's take a closer look at the API commands we've learned:
Curl-xput ' Localhost:9200/customer '
Curl-xput ' LOCALHOST:9200/CUSTOMER/EXTERNAL/1 '-d '
{
"Name": "John Doe"
}'
Curl ' LOCALHOST:9200/CUSTOMER/EXTERNAL/1 '
Curl-xdelete ' Localhost:9200/customer '

With a careful look at the above commands, we can find a pattern to access the data in Elasticsearch. This pattern can be summed up as:
Curl-x<rest verb> <Node>:<Port>/<Index>/<Type>/<ID>

This rest access pattern is universally applicable to all API commands, and if you can remember it, you'll have a good head start for mastering Elasticsearch.