windows:
.\elasticsearch.bat
.\elasticsearch.bat -E path.data=data2 -E path.logs=log2
.\elasticsearch.bat -E path.data=data3 -E path.logs=log3
The additional nodes are assigned unique IDs. Because you’re running all three nodes locally, they automatically join the cluster with the first node.
index
0.Request
PUT /<target>/_doc/<_id>
POST /<target>/_doc/
PUT /<target>/_create/<_id>
POST /<target>/_create/<_id>
1.Automatically create data streams and indices
action.auto_create_index
PUT _cluster/settings
{ "persistent": { "action.auto_create_index": "my-index-000001,index10,-index1*,+ind*" }}
Allow auto-creation of indices called my-index-000001 or index10, block the creation of indices that match the pattern index1*, and allow creation of any other indices that match the ind* pattern. Patterns are matched in the order specified.
允许创建my-index-000001 或 index10。不允许创建index1*，允许创建+ind*。减号不允许，加号允许
action.auto_create_index
PUT _cluster/settings{ "persistent": { "action.auto_create_index": "true" }}
Allow automatic creation of any index. This is the default.
2.Create document IDs automatically
POST my-index-000001/_doc/{ "@timestamp": "2099-11-15T13:12:00", "message": "GET /search HTTP/1.1 200 1070000", "user": { "id": "kimchy" }}
When using the POST /<target>/_doc/ request format, the op_type is automatically set to create and the index operation generates a unique ID for the document.
3.routing
By default, shard placement — or routing— is controlled by using a hash of the document’s id value. For more explicit control, the value fed into the hash function used by the router can be directly specified on a per-operation basis using the routing parameter. For example:
POST my-index-000001/_doc?routing=kimchy{ "@timestamp": "2099-11-15T13:12:00", "message": "GET /search HTTP/1.1 200 1070000", "user": { "id": "kimchy" }}
In this example, the document is routed to a shard based on the routing parameter provided: "kimchy".
4.Timeout
The primary shard assigned to perform the index operation might not be available when the index operation is executed. Some reasons for this might be that the primary shard is currently recovering from a gateway or undergoing relocation. By default, the index operation will wait on the primary shard to become available for up to 1 minute before failing and responding with an error. The timeout parameter can be used to explicitly specify how long it waits. Here is an example of setting it to 5 minutes:
PUT my-index-000001/_doc/1?timeout=5m{ "@timestamp": "2099-11-15T13:12:00", "message": "GET /search HTTP/1.1 200 1070000", "user": { "id": "kimchy" }}
GET
0.Request
GET <index>/_doc/<_id>
HEAD <index>/_doc/<_id>
GET <index>/_source/<_id>
HEAD <index>/_source/<_id>
1.Description
GET my-index-000001/_doc/0?XXX 后边的
1.1Realtime
By default, the get API is realtime, and is not affected by the refresh rate of the index (when data will become visible for search). In case where stored fields are requested (see stored_fields parameter) and the document has been updated but is not yet refreshed, the get API will have to parse and analyze the source to extract the stored fields. In order to disable realtime GET, the realtime parameter can be set to false.
1.2Source filtering
By default, the get operation returns the contents of the _source field unless you have used the stored_fields parameter or if the _source field is disabled. You can turn off _source retrieval by using the _source parameter:
GET my-index-000001/_doc/0?_source=false
GET my-index-000001/_doc/0?_source_includes=*.id&_source_excludes=entities
GET my-index-000001/_doc/0?_source=*.id
1.3Routing
If routing is used during indexing, the routing value also needs to be specified to retrieve a document. For example:
GET my-index-000001/_doc/2?routing=user1
