Как вы знаете, данные в индексе разделены на один или несколько осколков. Разделив ваши данные на несколько осколков, Elasticsearch может масштабироваться за пределы того, что может сделать одна машина. Elasticsearch — это распределенная система, и системные сбои обязательно произойдут. Поскольку каждый осколок является независимым индексом Lucene, который может жить на любом узле кластера, Elasticsearch обеспечивает способ сохранения копии первичного осколка в другом узле кластера. Если узел, содержащий первичный осколок, терпит неудачу, то осколок реплики (копия), который существует в другом узле, продвигается до первичного.
В этом разделе мы поговорим о том, как синхронизируются данные между первичной и репликой:
Скажем, у нас есть кластер из двух узлов, как показано на рисунке. Осколки, представленные сплошными линиями, являются первичными осколками, а осколки, представленные пунктирными линиями, являются репликами. Мы индексируем документ в индекс example4 и тип person, как показано здесь:
PUT http://node2:9200/example4/person/4
{
"id": 4,
"name": "user4",
"age": "55",
"gender": "M",
"email": "[email protected]",
"last_modified_date" : "2017-02-20"
}
Произойдет следующее:
- Запрос может быть отправлен на любой узел в кластере, а узел, получающий запрос, называется координационным узлом.
- Координационный узел использует идентификатор документа или значение маршрутизации для определения осколка, на котором должна выполняться операция. В этом примере предположим, что предыдущий документ с идентификатором 1 принадлежит S1.
- Внутренне, запрос направляется в первичный осколок S1 в Node 1.
- Основной осколок выполняет операцию локально и отправляет запрос ко всем репликам параллельно.
- Как только все реплики возвращаются к первичному, подтверждение возвращается клиенту.
Теперь давайте посмотрим на ответ в операции:
{
"_index": "example4",
"_type": "person",
"_id": "4",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 2,
"failed": 0
},
"created": true
}
Давайте посмотрим на _shards из ответа. Вы можете видеть, что общее количество осколков 2 (первичные и реплики), и оба они успешны.
Хочу на первичной осколок!
Поскольку запрос сначала выполняется на первичном осколке, а затем перенаправляется на реплики, может быть время, когда данные из первичной части отличаются от реплики. Если вашему приложению всегда нужны самые последние данные, вы можете использовать свойство предпочтения для управления тем, на каком типе осколка выполниться запрос.
Рассмотрим следующий пример:
POST example4/person/_search?preference=_primary
{
"query": {
"match": {
"name": "user1"
}
}
}
Предыдущий запрос будет выполнен только на первичных осколках. Другой вариант _primary_first. Запрос выполняется сначала по первичному, и если первичный файл недоступен, он выполняется на осколке реплики:
POST example4/person/_search?preference=_primary_first
{
"query": {
"match": {
"name": "user1"
}
}
}
Дополнительные реплики в угоду пропускной способности
Реплики не только помогают с отказом, но и увеличивают пропускную способность. Реплика — это точная копия первичного осколка и размещается в разных узлах кластера. Запросы обычно рандомизируются между первичными и репликами.
Если ваше приложение начинает не справлять с запросами на чтение, вам следует подумать об увеличении количества реплик.
Увеличение/уменьшение количества реплик
Мы можем увеличивать и уменьшать количество реплик индекса «на лету»:
PUT example4/_settings
{
"index" : {
"number_of_replicas" : 0
}
}
Вы должны увидеть ответ, подобный этому:
{"acknowledged":true}