web-dev-qa-db-fra.com

Le fragment primaire n'est pas actif ou n'est pas attribué est un nœud connu?

J'utilise une version de recherche élastique 4.1 sur Windows 8. J'ai essayé d'indexer un document via Java. Lors de l'exécution d'un test JUNIT, l'erreur apparaît comme ci-dessous. 

org.elasticsearch.action.UnavailableShardsException: [wms][3] Primary shard is not active or isn't assigned is a known node. Timeout: [1m], request: index {[wms][video][AUpdb-bMQ3rfSDgdctGY], source[{
    "fleetNumber": "45",
    "timestamp": "1245657888",
    "geoTag": "73.0012312,-123.00909",
    "videoName": "timestamp.mjpeg",
    "content": "ASD123124NMMM"
}]}
    at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.retryBecauseUnavailable(TransportShardReplicationOperationAction.Java:784)
    at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.doStart(TransportShardReplicationOperationAction.Java:402)
    at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$3.onTimeout(TransportShardReplicationOperationAction.Java:500)
    at org.elasticsearch.cluster.ClusterStateObserver$ObserverClusterStateListener.onTimeout(ClusterStateObserver.Java:239)
    at org.elasticsearch.cluster.service.InternalClusterService$NotifyTimeout.run(InternalClusterService.Java:497)
    at Java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.Java:1145)
    at Java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.Java:615)
    at Java.lang.Thread.run(Thread.Java:722)

Je ne peux pas comprendre pourquoi cette erreur se produit. Lorsque vous supprimez une donnée ou un index, cela fonctionne bien. Quelle pourrait en être la cause possible. 

javaindexingelasticsearchsharding
15
Prem Singh Bist

vous devriez regarder ce lien: http://www.elasticsearch.org/guide/fr/elasticsearch/reference/current/index-modules-allocation.html

et cette partie en particulier:

cluster.routing.allocation.disk.watermark.low contrôle le niveau bas filigrane pour l'utilisation du disque. La valeur par défaut est 85%, ce qui signifie que ES ne le fera pas allouez de nouveaux fragments aux nœuds une fois qu'ils ont utilisé plus de 85% du disque . Vous pouvez également définir une valeur d'octet absolu (500 Mo par exemple) pour empêcher ES à partir d'allouer des fragments si inférieur à la quantité d'espace configurée est disponible.

cluster.routing.allocation.disk.watermark.high contrôle le niveau haut filigrane. La valeur par défaut est 90%, ce qui signifie que ES tentera de déménager des fragments vers un autre nœud si l'utilisation du disque du nœud dépasse 90%. Ça peut également être défini sur une valeur absolue en octets (similaire au filigrane bas) pour déplacer des fragments une fois inférieurs à la quantité d'espace configurée, c'est disponible sur le noeud.

17
Alexandre Mélard

Dans mon cas, le coupable était le port 9300. Il était bloqué.

Elasticsearch sera lié à un seul port pour HTTP et le API de nœud/transport.

Il essaiera d’abord le port disponible le plus bas, et s’il est déjà pris, essayez le suivant. Si vous exécutez un seul nœud sur votre machine, il ne restera que lie à 9200 et 9300.

J'ai donc débloqué le port 9300 et j'étais prêt à partir.

Dans REDHAT linux pour débloquer un port.

Sudo firewall-cmd --zone=public --add-port=9300/tcp --permanent
Sudo firewall-cmd --reload
Sudo iptables-save | grep 9300
1
Zeeshan

J'ai rencontré exactement la même erreur et dans mon cas, j'avais plusieurs nœuds maîtres et de données. Les nœuds maîtres ont été ajoutés à l'équilibreur de charge, mais pas les nœuds de données. Le maître n’a donc pas pu communiquer avec le nœud de données.

Dès que j'ai apporté tous les nœuds de données dans l'équilibreur de charge, mon problème a été résolu.

0
avp