Elasticsearch hard
Changing `index.translog.durability` from `request` to `async` can drastically increase indexing WPS (Writes Per Second). What is the specific data loss risk (RPO)?
- A The index mapping will become corrupted if the node restarts unexpectedly.
- B You risk losing any writes acknowledged within the last `sync_interval` (default 5 seconds) if the server hardware fails or loses power before the in-memory buffer is flushed to disk via fsync.
- C Replicas will stop receiving updates, causing the cluster to enter a 'Red' status.
- D The JVM will disable the G1 Garbage Collector to prioritize disk I/O threads.
Answer: B. You risk losing any writes acknowledged within the last `sync_interval` (default 5 seconds) if the server hardware fails or loses power before the in-memory buffer is flushed to disk via fsync.
With `durability: request`, ES doesn't return a `200 OK` until the write is physically on disk. With `async`, it returns `200 OK` once it's in a memory buffer. This is a classic 'Performance vs. Safety' trade-off used for high-velocity logs where losing 5 seconds of data is acceptable.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What are the two primary reasons for configuring one or more 'Replica Shards' for an index?
- When a String field is mapped as `text`, what process is performed to enable full-text search capability?
- What is the primary benefit of splitting an Elasticsearch index into multiple 'Primary Shards'?
- Every document stored in an Elasticsearch index is uniquely tracked by which mandatory metadata field?
- Elasticsearch search results include a metadata field called `_score`. What does this value primarily indicate?
- What is the primary architectural purpose of Elasticsearch in a modern software stack?