Tanguy Leroux 656596c2a9 [DOC] Remove obsolete node names from documentation
Funny node names have been removed in  and replaced by UUID. This commit removes these obsolete node names and replace them by real UUIDs in the documentation.

closes 
2016-09-19 11:56:28 +02:00

114 lines
4.7 KiB
Plaintext

[[cat-shards]]
== cat shards
The `shards` command is the detailed view of what nodes contain which
shards. It will tell you if it's a primary or replica, the number of
docs, the bytes it takes on disk, and the node where it's located.
Here we see a single index, with three primary shards and no replicas:
[source,sh]
--------------------------------------------------
% curl 192.168.56.20:9200/_cat/shards
wiki1 0 p STARTED 3014 31.1mb 192.168.56.10 H5dfFeA
wiki1 1 p STARTED 3013 29.6mb 192.168.56.30 bGG90GE
wiki1 2 p STARTED 3973 38.1mb 192.168.56.20 I8hydUG
--------------------------------------------------
[float]
[[index-pattern]]
=== Index pattern
If you have many shards, you may wish to limit which indices show up
in the output. You can always do this with `grep`, but you can save
some bandwidth by supplying an index pattern to the end.
[source,sh]
--------------------------------------------------
% curl 192.168.56.20:9200/_cat/shards/wiki*
wiki2 0 p STARTED 197 3.2mb 192.168.56.10 H5dfFeA
wiki2 1 p STARTED 205 5.9mb 192.168.56.30 bGG90GE
wiki2 2 p STARTED 275 7.8mb 192.168.56.20 I8hydUG
--------------------------------------------------
[float]
[[relocation]]
=== Relocation
Let's say you've checked your health and you see two relocating
shards. Where are they from and where are they going?
[source,sh]
--------------------------------------------------
% curl 192.168.56.10:9200/_cat/health
1384315316 20:01:56 foo green 3 3 12 6 2 0 0
% curl 192.168.56.10:9200/_cat/shards | fgrep RELO
wiki1 0 r RELOCATING 3014 31.1mb 192.168.56.20 I8hydUG -> 192.168.56.30 bGG90GE
wiki1 1 r RELOCATING 3013 29.6mb 192.168.56.10 H5dfFeA -> 192.168.56.30 bGG90GE
--------------------------------------------------
[float]
[[states]]
=== Shard states
Before a shard can be used, it goes through an `INITIALIZING` state.
`shards` can show you which ones.
[source,sh]
--------------------------------------------------
% curl -XPUT 192.168.56.20:9200/_settings -d'{"number_of_replicas":1}'
{"acknowledged":true}
% curl 192.168.56.20:9200/_cat/shards
wiki1 0 p STARTED 3014 31.1mb 192.168.56.10 H5dfFeA
wiki1 0 r INITIALIZING 0 14.3mb 192.168.56.30 bGG90GE
wiki1 1 p STARTED 3013 29.6mb 192.168.56.30 bGG90GE
wiki1 1 r INITIALIZING 0 13.1mb 192.168.56.20 I8hydUG
wiki1 2 r INITIALIZING 0 14mb 192.168.56.10 H5dfFeA
wiki1 2 p STARTED 3973 38.1mb 192.168.56.20 I8hydUG
--------------------------------------------------
If a shard cannot be assigned, for example you've overallocated the
number of replicas for the number of nodes in the cluster, the shard
will remain `UNASSIGNED` with the <<reason-unassigned,reason code>> `ALLOCATION_FAILED`.
[source,sh]
--------------------------------------------------
% curl -XPUT 192.168.56.20:9200/_settings -d'{"number_of_replicas":3}'
% curl 192.168.56.20:9200/_cat/health
1384316325 20:18:45 foo yellow 3 3 9 3 0 0 3
% curl 192.168.56.20:9200/_cat/shards
wiki1 0 p STARTED 3014 31.1mb 192.168.56.10 H5dfFeA
wiki1 0 r STARTED 3014 31.1mb 192.168.56.30 bGG90GE
wiki1 0 r STARTED 3014 31.1mb 192.168.56.20 I8hydUG
wiki1 0 r UNASSIGNED ALLOCATION_FAILED
wiki1 1 r STARTED 3013 29.6mb 192.168.56.10 H5dfFeA
wiki1 1 p STARTED 3013 29.6mb 192.168.56.30 bGG90GE
wiki1 1 r STARTED 3013 29.6mb 192.168.56.20 I8hydUG
wiki1 1 r UNASSIGNED ALLOCATION_FAILED
wiki1 2 r STARTED 3973 38.1mb 192.168.56.10 H5dfFeA
wiki1 2 r STARTED 3973 38.1mb 192.168.56.30 bGG90GE
wiki1 2 p STARTED 3973 38.1mb 192.168.56.20 I8hydUG
wiki1 2 r UNASSIGNED ALLOCATION_FAILED
--------------------------------------------------
[float]
[[reason-unassigned]]
=== Reasons for unassigned shard
These are the possible reasons for a shard be in a unassigned state:
[horizontal]
`INDEX_CREATED`:: Unassigned as a result of an API creation of an index.
`CLUSTER_RECOVERED`:: Unassigned as a result of a full cluster recovery.
`INDEX_REOPENED`:: Unassigned as a result of opening a closed index.
`DANGLING_INDEX_IMPORTED`:: Unassigned as a result of importing a dangling index.
`NEW_INDEX_RESTORED`:: Unassigned as a result of restoring into a new index.
`EXISTING_INDEX_RESTORED`:: Unassigned as a result of restoring into a closed index.
`REPLICA_ADDED`:: Unassigned as a result of explicit addition of a replica.
`ALLOCATION_FAILED`:: Unassigned as a result of a failed allocation of the shard.
`NODE_LEFT`:: Unassigned as a result of the node hosting it leaving the cluster.
`REROUTE_CANCELLED`:: Unassigned as a result of explicit cancel reroute command.
`REINITIALIZED`:: When a shard moves from started back to initializing, for example, with shadow replicas.
`REALLOCATED_REPLICA`:: A better replica location is identified and causes the existing replica allocation to be cancelled.