Как исправить желтый цвет желтого цвета с помощью Elastic Search

Ответ 1

Кластер конфигурируется с тем же именем кластера внутри конфигурации упругого поиска

По умолчанию elasticsearch.yml, который вы, вероятно, используете, имеет следующие настройки в начале:

################################### Cluster ###################################

# Cluster name identifies your cluster for auto-discovery. If you're running
# multiple clusters on the same network, make sure you're using unique names.
#
# cluster.name: elasticsearch


#################################### Node #####################################

# Node names are generated dynamically on startup, so you're relieved
# from configuring them manually. You can tie this node to a specific name:
#
# node.name: "Franz Kafka"

здесь вам нужно будет настроить уникальный

cluster.name: "MainCluster"

и для каждой машины и/или экземпляра другой уникальный

node.name: "LocalMachine1"

теперь вам нужно скопировать этот elasticsearch.yml на другой компьютер (в той же сети) или на то же место, что, например, elasticsearch_2.yml изменить его для:

node.name: "LocalMachine2"

и ваш кластер готов к работе

Если не сконфигурирован, elastiscsearch будет использовать случайный символ Marvel (3000 в соответствии с документацией), поэтому не менять node.name должно быть также хорошо.

Для того, чтобы два узла работали на одном компьютере, вы должны сделать конфигурацию, например. elasticsearch_2.yml копия с приведенными выше изменениями. Также вы должны иметь копии данных и путь к журналу например (исходные конкретные пути:)

cp -r /usr/local/var/elasticsearch /usr/local/var/elasticsearch_2
cp -r /usr/local/var/log/elasticsearch /usr/local/var/log/elasticsearch_2

может выглядеть как

#################################### Paths ####################################

# Path to directory containing configuration (this file and logging.yml):
#
# path.conf: /path/to/conf

# Path to directory where to store index data allocated for this node.
#
path.data: /usr/local/var/elasticsearch_2/
#
# Can optionally include more than one location, causing data to be striped across
# the locations (a la RAID 0) on a file level, favouring locations with most free
# space on creation. For example:
#
# path.data: /path/to/data1,/path/to/data2

# Path to temporary files:
#
# path.work: /path/to/work

# Path to log files:
#
path.logs: /usr/local/var/log/elasticsearch_2/

убедитесь, что у вас нет запуска elasicsearch на локальном устройстве loopback

127.0.0.1

просто прокомментируйте это, если это не так (homebrew делает patch ist таким образом)

############################## Network And HTTP ###############################

# Elasticsearch, by default, binds itself to the 0.0.0.0 address, and listens
# on port [9200-9300] for HTTP traffic and on port [9300-9400] for node-to-node
# communication. (the range means that if the port is busy, it will automatically
# try the next port).

# Set the bind address specifically (IPv4 or IPv6):
#
# network.bind_host: 192.168.0.1

# Set the address other nodes will use to communicate with this node. If not
# set, it is automatically derived. It must point to an actual IP address.
#
# network.publish_host: 192.168.0.1

# Set both 'bind_host' and 'publish_host':
#
# network.host: 127.0.0.1

теперь вы можете начать поиск упругого типа следующим образом:

bin/elasticsearch -D es.config=/usr/local/Cellar/elasticsearch/1.0.0.RC1/config/elasticsearch.yml

для первого node и master (потому что начато сначала)

а затем

bin/elasticsearch -D es.config=/usr/local/Cellar/elasticsearch/1.0.0.RC1/config/elasticsearch_2.yml

Теперь у вас должно быть 2 узла с

Ответ 2

Похоже, у вас нет node для черепов реплик. Вы можете уменьшить счетчик реплик до 0 или добавить второй кластер node в кластер, чтобы первичные и реплики могли безопасно размещаться на разных узлах.

Конфигурация по умолчанию в elasticsearch.yml, вероятно, такова:

index.number_of_shards: 5  
index.number_of_replicas: 1

Идея состоит в том, что если ваш node сбой, другой node в вашем кластере будет иметь копию осколка. Поскольку у вас есть только один node, в кластере нет места для размещения реплик и, следовательно, находится в желтом состоянии.

Ответ 3

Я отправляю ответ, так как я обрушился на этот вопрос, ища решение подобной проблемы.

У меня есть среда dev, где мне нужен только 1 Elasticsearch node, поэтому нет необходимости в репликах для всех моих индексов.

Чтобы решить проблему здоровье кластера: желтый, я просто сделал index.number_of_replicas: 1

PUT /_settings
{
  "index" : {
        "number_of_replicas" : 0
    }
}