Чтение и запись документов

Каждый индекс в Elasticsearch разделен на фрагменты (shards), и каждый фрагмент может иметь несколько копий. Эти копии известны как группа репликации (replication group) и должны быть синхронизированы при добавлении или удалении документов. Если этого не сделать, чтение из одной копии даст существенно отличающиеся результаты от чтения из другой. Процесс синхронизации копий фрагментов и обслуживания чтений из них называется моделью репликации данных.

Модель репликации данных Elasticsearch основана на модели первичного-резервного копирования и подробно описана в статье PacificA исследовательского центра Microsoft. Эта модель предполагает наличие одной копии из группы репликации, которая выступает в качестве первичного фрагмента. Другие копии называются фрагментами-репликами. Первичный фрагмент служит основным входом для всех операций индексирования. Он отвечает за проверку операций и гарантию их корректности. После того, как операция индексирования была принята первичным фрагментом, первичный фрагмент также отвечает за репликацию операции на другие копии.

Цель этого раздела — дать общее представление о модели репликации Elasticsearch и обсудить последствия, которые она имеет для различных взаимодействий между операциями записи и чтения.

Каждая операция индексирования в Elasticsearch сначала обрабатывается группой репликации с использованием маршрутизации, как правило, на основе идентификатора документа. После определения группы репликации операция передаётся внутренне текущему первичному фрагменту группы. Эта стадия индексирования называется этапом координации.

Следующий этап индексирования — этап первичного фрагмента, выполняемый на первичном фрагменте. Первичный фрагмент отвечает за проверку операции и её передачу другим репликам. Так как реплики могут быть недоступны, первичный фрагмент не обязан реплицировать операции на все реплики. Вместо этого Elasticsearch поддерживает список копий фрагментов, которые должны получить операцию. Этот список называется синхронизированными копиями и поддерживается главным узлом. Как следует из названия, это набор «хороших» копий фрагментов, которые гарантированно обработали все операции индексирования и удаления, подтверждённые пользователю. Первичный фрагмент отвечает за поддержание этого инварианта и, следовательно, должен реплицировать все операции на каждую копию в этом наборе.

Первичный фрагмент выполняет следующие действия:

Каждая синхронизированная копия реплики выполняет операцию индексирования локально, чтобы иметь её копию. Эта стадия индексирования называется этапом реплики.

Эти этапы индексирования (координации, первичного и реплики) последовательны. Для возможности внутренних повторов срок действия каждого этапа охватывает срок действия последующего этапа. Например, этап координации не завершается до тех пор, пока не завершится каждый этап первичного фрагмента, который может распространяться на разные первичные фрагменты. Каждый этап первичного фрагмента не завершится, пока синхронизированные реплики не закончат локальное индексирование документов и не ответят на запросы реплик.

При индексировании могут возникнуть различные проблемы — жёсткий диск может выйти из строя, узлы могут потерять связь друг с другом, или ошибка в конфигурации может привести к сбою операции на реплике, несмотря на её успешное выполнение на первичном фрагменте. Такие ситуации редкие, но первичный фрагмент должен реагировать на них.

Если первичный фрагмент выйдет из строя, узел, на котором он размещён, отправит сообщение мастер-узлу об этом. Операция индексирования будет ожидать (до 1 минуты по умолчанию) до тех пор, пока мастер-узел не повысит одну из реплик до статуса нового первичного фрагмента. Затем операция будет передана новому первичному фрагменту для обработки. Обратите внимание, что мастер-узел также следит за состоянием узлов и может принять решение о понижении первичного фрагмента. Это обычно происходит, когда узел, содержащий первичный фрагмент, изолирован от кластера из-за сетевой проблемы. Дополнительные сведения см. в разделе здесь.

После успешного выполнения операции на первичном фрагменте, первичный фрагмент должен обрабатывать возможные ошибки при её выполнении на фрагментах-репликах. Это может быть вызвано фактическим сбоем реплики или проблемой сети, из-за которой операция не может достичь реплики (или реплика не может ответить). Все эти ситуации приводят к тому, что реплика, входящая в набор синхронизированных реплик, пропускает операцию, которая должна быть подтверждена. Для предотвращения нарушения инварианта первичный фрагмент отправляет сообщение мастер-узлу, запрашивая удаление проблемного фрагмента из набора синхронизированных реплик. Только после подтверждения удаления фрагмента мастер-узлом первичный фрагмент подтверждает операцию. Обратите внимание, что мастер-узел также даст указание другому узлу начать создание новой копии фрагмента, чтобы восстановить систему в рабочее состояние.

При передаче операции репликам первичный фрагмент использует их для проверки, является ли он активным первичным фрагментом. Если первичный фрагмент изолирован из-за сетевого разрыва (или длительного сборки мусора) он может продолжить обработку входящих операций индексирования, прежде чем осознать, что он был понижен. Операции, поступающие от устаревшего первичного фрагмента, будут отклонены репликами. Когда первичный фрагмент получает ответ от реплики с отклонением запроса, поскольку он больше не является первичным, он обращается к мастер-узлу и узнаёт, что он был заменён. Затем операция направляется новому первичному фрагменту.

Чтения в Elasticsearch могут быть лёгкими запросами по идентификатору или сложными запросами поиска с комплексными агрегациями, требующими значительных вычислительных ресурсов. Одно из преимуществ модели первичного-резервного копирования заключается в том, что все копии фрагментов идентичны (за исключением операций в процессе). Таким образом, одной синхронизированной копии достаточно для обслуживания запросов чтения.

Когда узел получает запрос чтения, он отвечает за его перенаправление на узлы, хранящие соответствующие фрагменты, сборку ответов и ответ клиенту. Мы называем этот узел координирующим узлом для этого запроса. Базовый порядок действий следующий:

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

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

Ответы, содержащие частичные результаты, всё равно содержат 200 OK код состояния HTTP. Ошибки фрагментов указаны в полях timed_out и _shards заголовка ответа.

Каждый из этих базовых потоков определяет поведение Elasticsearch как системы для чтения и записи. Кроме того, поскольку запросы чтения и записи могут выполняться параллельно, эти два базовых потока взаимодействуют друг с другом. Это влечёт за собой несколько последствий:

В случае ошибок возможно следующее:

Этот документ предоставляет общее представление о том, как Elasticsearch обрабатывает данные. Конечно, происходит гораздо больше. Такие вещи, как первичные термины, публикация состояния кластера и выбор мастера, играют важную роль в правильной работе этой системы. В этом документе также не рассматриваются известные и важные ошибки (как закрытые, так и открытые). Мы понимаем, что GitHub сложно отслеживать. Чтобы помочь людям следить за ними, мы поддерживаем специальную страницу восстановления на нашем сайте. Мы настоятельно рекомендуем её прочитать.