evolix/wiki
22
0
Fork 0
Code Releases Activity

Plus d'exemples pour les API _cat, _cluster…

Browse source
This commit is contained in:
Jérémy Lecour 2019-08-01 09:56:29 +02:00 committed by Jérémy Lecour
parent 97f5c4c03c
commit d772379708
1 changed files with 99 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

100
HowtoElasticsearch.md
View file

@ -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"