mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-10 06:55:32 +00:00
4a4e3d70d5
This commit changes the default out-of-the-box configuration for the number of shards from five to one. We think this will help address a common problem of oversharding. For users with time-based indices that need a different default, this can be managed with index templates. For users with non-time-based indices that find they need to re-shard with the split API in place they no longer need to resort only to reindexing. Since this has the impact of changing the default number of shards used in REST tests, we want to ensure that we still have coverage for issues that could arise from multiple shards. As such, we randomize (rarely) the default number of shards in REST tests to two. This is managed via a global index template. However, some tests check the templates that are in the cluster state during the test. Since this template is randomly there, we need a way for tests to skip adding the template used to set the number of shards to two. For this we add the default_shards feature skip. To avoid having to write our docs in a complicated way because sometimes they might be behind one shard, and sometimes they might be behind two shards we apply the default_shards feature skip to all docs tests. That is, these tests will always run with the default number of shards (one).
125 lines
4.4 KiB
Plaintext
125 lines
4.4 KiB
Plaintext
[[cluster-health]]
|
|
== Cluster Health
|
|
|
|
The cluster health API allows to get a very simple status on the health
|
|
of the cluster. For example, on a quiet single node cluster with a single index
|
|
with one shard and one replica, this:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET _cluster/health
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[s/^/PUT test1\n/]
|
|
|
|
Returns this:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
{
|
|
"cluster_name" : "testcluster",
|
|
"status" : "yellow",
|
|
"timed_out" : false,
|
|
"number_of_nodes" : 1,
|
|
"number_of_data_nodes" : 1,
|
|
"active_primary_shards" : 1,
|
|
"active_shards" : 1,
|
|
"relocating_shards" : 0,
|
|
"initializing_shards" : 0,
|
|
"unassigned_shards" : 1,
|
|
"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": 50.0
|
|
}
|
|
--------------------------------------------------
|
|
// TESTRESPONSE[s/testcluster/docs_integTestCluster/]
|
|
// TESTRESPONSE[s/"number_of_pending_tasks" : 0,/"number_of_pending_tasks" : $body.number_of_pending_tasks,/]
|
|
// TESTRESPONSE[s/"task_max_waiting_in_queue_millis": 0/"task_max_waiting_in_queue_millis": $body.task_max_waiting_in_queue_millis/]
|
|
|
|
|
|
The API can also be executed against one or more indices to get just the
|
|
specified indices health:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_cluster/health/test1,test2
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[s/^/PUT test1\nPUT test2\n/]
|
|
|
|
The cluster health status is: `green`, `yellow` or `red`. On the shard
|
|
level, a `red` status indicates that the specific shard is not allocated
|
|
in the cluster, `yellow` means that the primary shard is allocated but
|
|
replicas are not, and `green` means that all shards are allocated. The
|
|
index level status is controlled by the worst shard status. The cluster
|
|
status is controlled by the worst index status.
|
|
|
|
One of the main benefits of the API is the ability to wait until the
|
|
cluster reaches a certain high water-mark health level. For example, the
|
|
following will wait for 50 seconds for the cluster to reach the `yellow`
|
|
level (if it reaches the `green` or `yellow` status before 50 seconds elapse,
|
|
it will return at that point):
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_cluster/health?wait_for_status=yellow&timeout=50s
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
[float]
|
|
[[request-params]]
|
|
=== Request Parameters
|
|
|
|
The cluster health API accepts the following request parameters:
|
|
|
|
`level`::
|
|
Can be one of `cluster`, `indices` or `shards`. Controls the
|
|
details level of the health information returned. Defaults to `cluster`.
|
|
|
|
`wait_for_status`::
|
|
One of `green`, `yellow` or `red`. Will wait (until
|
|
the timeout provided) until the status of the cluster changes to the one
|
|
provided or better, i.e. `green` > `yellow` > `red`. By default, will not
|
|
wait for any status.
|
|
|
|
`wait_for_no_relocating_shards`::
|
|
A boolean value which controls whether to wait (until the timeout provided)
|
|
for the cluster to have no shard relocations. Defaults to false, which means
|
|
it will not wait for relocating shards.
|
|
|
|
`wait_for_no_initializing_shards`::
|
|
A boolean value which controls whether to wait (until the timeout provided)
|
|
for the cluster to have no shard initializations. Defaults to false, which means
|
|
it will not wait for initializing shards.
|
|
|
|
`wait_for_active_shards`::
|
|
A number controlling to how many active shards to wait for, `all` to wait
|
|
for all shards in the cluster to be active, or `0` to not wait. Defaults to `0`.
|
|
|
|
`wait_for_nodes`::
|
|
The request waits until the specified number `N` of
|
|
nodes is available. It also accepts `>=N`, `<=N`, `>N` and `<N`.
|
|
Alternatively, it is possible to use `ge(N)`, `le(N)`, `gt(N)` and
|
|
`lt(N)` notation.
|
|
|
|
`timeout`::
|
|
A time based parameter controlling how long to wait if one of
|
|
the wait_for_XXX are provided. Defaults to `30s`.
|
|
|
|
`local`::
|
|
If `true` returns the local node information and does not provide
|
|
the state from master node. Default: `false`.
|
|
|
|
|
|
The following is an example of getting the cluster health at the
|
|
`shards` level:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_cluster/health/twitter?level=shards
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|