Elasticsearch: shard routing, near-real-time search and safe coordination

Elasticsearch — distributed search engine with a primary/replica shard model. Correctness requires not смешивать indexing ACK, Lucene refresh visibility, translog/recovery и master-eligible voting.

Корректная модель

• Index acknowledgement, translog durability and search refresh visibility are separate.
• A primary shard orders each document operation; replicas apply the resulting operation asynchronously/concurrently with safeguards.
• Search can fan out and return partial shard failures; clients must inspect response semantics.
• cluster.initial_master_nodes is only for first bootstrap and must not be reused on restarts.

Границы и компоненты

Сценарии

Primary-ordered document indexing

The coordinating node routes by document ID to one primary. The primary validates and assigns ordering metadata before parallel replica requests.

Проверяемый исход: The response reports actual successful/failed shard copies; it is not described as a mandatory 3-of-3 quorum.

Near-real-time search visibility

A successful index response does not imply immediate search visibility. Refresh opens a new segment; real-time GET and search have different paths.

Проверяемый исход: Caller selects refresh=wait_for only when its latency/throughput trade-off is justified.

Optimistic concurrency conflict

A client updates only if both if_seq_no and if_primary_term match the version it read. Another committed mutation makes the stale precondition fail.

Проверяемый исход: Lost update becomes an explicit 409/re-read decision rather than last-writer-wins by accident.

Safe cluster recovery

A formed cluster retains its cluster UUID. Restarting nodes discover that cluster; they never reuse initial bootstrap settings. Lost shards recover from peers or verified snapshots.

Проверяемый исход: No accidental second cluster is bootstrapped, and replicas are not mistaken for backups.

Failure, concurrency и replay checklist

• Use seq_no plus primary_term for conditional writes.
• Treat replica count as availability/read scale, not backup retention.
• Monitor unassigned shards, rejected writes, refresh/merge pressure and partial search failures.
• Verify snapshot restore and remove first-bootstrap configuration after formation.

Формулы, units и допущения

• Primary shard count fixes maximum routing fan-out and per-shard data size until reindex/split strategy; more shards add metadata and coordination overhead.
• Search latency is dominated by the slowest required shard response plus reduce time; average shard latency is insufficient.
• refresh interval is a configured visibility cadence, not a durability SLA or universal one-second guarantee under every setting.

Числа выше — учебные inputs или размерностные формулы. Их нельзя выдавать за benchmark или SLA конкретного продукта.

Связанные темы

[CONCEPT]database-replication-deep

[CONCEPT]mvcc

Первичные источники

• https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-replication.html
• https://www.elastic.co/docs/manage-data/data-store/near-real-time-search
• https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control
• https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-bootstrap-cluster.html

Scope note

Диаграмма показывает причинные границы и recovery contracts, а не скрытую реализацию конкретного managed-сервиса. Любая stronger guarantee действует только в явно названной transaction/checkpoint/acknowledgement boundary.