J'utilise elasticsearch sur ma machine locale. La taille du répertoire de données n’est que de 37 Mo, mais lorsque je vérifie les journaux, je peux voir:
[2015-05-17 21: 31: 12,905] [WARN] [cluster.routing.allocation.decider] [Chrome] Le filigrane en haut du disque [10%] est dépassé le [h9P4UqnCR5SrXxwZKpQ2LQ] [Chrome] gratuitement: 5.7gb [6.1%] , les fragments seront déplacés de ce noeud
Assez confus sur ce qui pourrait mal se passer. De l'aide?
... watermark.high contrôle le haut filigrane. La valeur par défaut est 90%, ce qui signifie que ES tentera de déplacer des fragments vers un autre nœud si l'utilisation du disque du nœud dépasse 90%.
La taille de votre index réel n'a pas d'importance; ce qui compte, c'est l'espace libre restant sur l'appareil.
Si les valeurs par défaut ne vous conviennent pas, vous devez les modifier.
Pour résoudre le problème dans lequel, le journal est enregistré comme suit:
le filigrane de disque haut [90%] est dépassé le [ytI5oTyYSsCVfrB6CWFL1g] [ytI5oTy] [/ var/lib/elasticsearch/nodes/0]. libre: 552.2mb [4.3%], les fragments seront déplacés de ce noeud
Vous pouvez mettre à jour le seuil en exécutant la requête curl suivante:
curl -XPUT "http://localhost:9200/_cluster/settings" -d'
{
"persistent": {
"cluster": {
"routing": {
"allocation.disk.threshold_enabled": false
}
}
}
}'
C'est un avertissement et n'affectera rien. Les processeurs de stockage (SP) utilisent des filigranes haut et bas pour déterminer quand vider leurs caches en écriture. La solution possible peut être de libérer de la mémoire
Et l'avertissement disparaîtra. Même avec l'affichage, les répliques ne seront pas affectées au nœud, ce qui est correct. Le elasticsearch fonctionnera bien.
cette commande curl légèrement modifiée à partir de Elasticsearch 6.4 docs a fonctionné pour moi:
curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
"transient": {
"cluster.routing.allocation.disk.watermark.low": "2gb",
"cluster.routing.allocation.disk.watermark.high": "1gb",
"cluster.routing.allocation.disk.watermark.flood_stage": "500mb",
"cluster.info.update.interval": "1m"
}
}
'
si la commande curl -XPUT aboutit, vous devriez voir les journaux comme celui-ci dans la fenêtre du terminal Elasticsearch:
[2018-08-24T07:16:05,584][INFO ][o.e.c.s.ClusterSettings ] [bhjM1bz] updating [cluster.routing.allocation.disk.watermark.low] from [85%] to [2gb]
[2018-08-24T07:16:05,585][INFO ][o.e.c.s.ClusterSettings ] [bhjM1bz] updating [cluster.routing.allocation.disk.watermark.high] from [90%] to [1gb]
[2018-08-24T07:16:05,585][INFO ][o.e.c.s.ClusterSettings ] [bhjM1bz] updating [cluster.routing.allocation.disk.watermark.flood_stage] from [95%] to [500mb]
[2018-08-24T07:16:05,585][INFO ][o.e.c.s.ClusterSettings ] [bhjM1bz] updating [cluster.info.update.interval] from [30s] to [1m]
https://www.elastic.co/guide/fr/elasticsearch/reference/current/disk-allocator.html
Au lieu de pourcentage, j'utilise des valeurs absolues et des valeurs d'augmentation pour une meilleure utilisation de l'espace (en pré-prod):
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.disk.threshold_enabled": true,
"cluster.routing.allocation.disk.watermark.low": "1g",
"cluster.routing.allocation.disk.watermark.high": "500m",
"cluster.info.update.interval": "5m"
}
}
Aussi, je réduis l'intervalle de mise en commun pour raccourcir les journaux ES)