Plus d'exemples pour les API _cat, _cluster…
This commit is contained in:
parent
97f5c4c03c
commit
d772379708
|
@ -795,10 +795,108 @@ On peut récupérer la liste de tous les index, classés par nom :
|
|||
$ curl -s 127.0.0.1:9200/_cat/indices | sort -k 3
|
||||
green open index1 vewTWN8WRB-2V6xIgE7oQQ 1 1 2190434 0 2gb 1gb
|
||||
green open index2 k0a2yjwSS_CKKSydoVzcoQ 1 1 2164950 0 1.9gb 1020.5mb
|
||||
green open index3 rMtU36wXSNS9q9w6BDp0sA 1 1 3156725 0 2.9gb 1.4gb
|
||||
green yellow index3 rMtU36wXSNS9q9w6BDp0sA 1 1 3156725 0 2.9gb 1.4gb
|
||||
[…]
|
||||
~~~
|
||||
|
||||
On peut limiter la liste selon la valeur de certaines colones (exemple :`health`) :
|
||||
|
||||
~~~
|
||||
$ curl -s 127.0.0.1:9200/_cat/indices?health=yellow
|
||||
green yellow index3 rMtU36wXSNS9q9w6BDp0sA 1 1 3156725 0 2.9gb 1.4gb
|
||||
~~~
|
||||
|
||||
### Consulter l'état des shards
|
||||
|
||||
On peut voir si les shards sont correctement alloués (`STARTED`) ou pas.
|
||||
|
||||
~~~
|
||||
$ curl -s 127.0.0.1:9200/_cat/shards
|
||||
index3 1 p STARTED 0 191b 10.0.0.13 node3
|
||||
index3 1 r STARTED 0 191b 10.0.0.12 node2
|
||||
index3 1 r UNASSIGNED
|
||||
~~~
|
||||
|
||||
Ici on voit que `index3` a un shard non alloué. Pour savoir pourquoi on eput interroger l'état de l'index à propos de ses chards :
|
||||
|
||||
~~~
|
||||
$ curl 127.0.0.1:9200/index3/_shard_stores?pretty
|
||||
{
|
||||
"indices" : {
|
||||
"index3" : {
|
||||
"shards" : {
|
||||
"1" : {
|
||||
"stores" : [
|
||||
{
|
||||
"wPZvU6MUQkmhSb4YrszYeA" : {
|
||||
"name" : "node3",
|
||||
"ephemeral_id" : "6EK7veXhQrKAi42UB_97Zw",
|
||||
"transport_address" : "10.0.0.13:9300",
|
||||
"attributes" : { }
|
||||
},
|
||||
"allocation_id" : "RkL8f2wNS5CVL-MJYVHDaA",
|
||||
"allocation" : "primary"
|
||||
},
|
||||
{
|
||||
"yuF0yDqHTeyj7Z3rDt9HXw" : {
|
||||
"name" : "node2",
|
||||
"ephemeral_id" : "sIkpMVcGTyCkXx4RDd_mgA",
|
||||
"transport_address" : "10.0.0.12:9300",
|
||||
"attributes" : { }
|
||||
},
|
||||
"allocation_id" : "-piepczfSEiyTV9vN-l5MQ",
|
||||
"allocation" : "replica"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
~~~
|
||||
|
||||
On voir qu'il y a bien un _primary_ mais un seul _replica_.
|
||||
On peut alors interroger le cluster sur l'état des allocations :
|
||||
|
||||
~~~
|
||||
$ curl '127.0.0.1:9200/_cluster/allocation/explain?pretty'
|
||||
~~~
|
||||
|
||||
La sortie est en JSON et peut être assez verbeuse.
|
||||
Elle contiendra des explications a priori assez claires sur d'éventuels soucis d'allocations de shards.
|
||||
Dans cet exemple (tronqué) un shard _replica_ ne peut pas être alloué sur un nœud dont la version d'Elasticsearch n'est pas cohérente.
|
||||
|
||||
~~~.json
|
||||
{
|
||||
"index" : "index3",
|
||||
"shard" : 1,
|
||||
"primary" : false,
|
||||
"current_state" : "unassigned",
|
||||
"unassigned_info" : {
|
||||
"reason" : "REPLICA_ADDED",
|
||||
"at" : "2019-07-31T07:04:15.845Z",
|
||||
"last_allocation_status" : "no_attempt"
|
||||
},
|
||||
"can_allocate" : "no",
|
||||
"allocate_explanation" : "cannot allocate because allocation is not permitted to any of the nodes",
|
||||
"node_allocation_decisions" : [
|
||||
{
|
||||
"node_id" : "--e8PpGsSKifZ5lFlDkW3A",
|
||||
"node_name" : "node1",
|
||||
"transport_address" : "10.0.0.11:9300",
|
||||
"node_decision" : "no",
|
||||
"deciders" : [
|
||||
{
|
||||
"decider" : "node_version",
|
||||
"decision" : "NO",
|
||||
"explanation" : "target node version [5.6.6] is older than the source node version [5.6.15]"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
~~~
|
||||
|
||||
## FAQ
|
||||
|
||||
### Erreur "failed to map segment from shared object: Operation not permitted"
|
||||
|
|
Loading…
Reference in a new issue