ElasticSearch Quality Control & Assurance 4 — Questions and Answers
Question 1: What is the correct way to verify that an Elasticsearch snapshot completed successfully and the data is restorable?
- Check that _cat/snapshots shows status=SUCCESS and perform a test restore to a separate index (Correct answer)
- Confirm the snapshot repository path is not empty
- Run _flush on the index after the snapshot
- Check that no red shards existed at snapshot time
Correct answer: Check that _cat/snapshots shows status=SUCCESS and perform a test restore to a separate index
Verifying snapshot integrity requires both a SUCCESS status and an actual test restore, since file-level corruption won't be detected by status alone.
Question 2: Which circuit breaker in Elasticsearch is specifically designed to prevent field data loading from exhausting heap memory?
- Request circuit breaker
- In-flight requests circuit breaker
- Fielddata circuit breaker (Correct answer)
- Parent circuit breaker
Correct answer: Fielddata circuit breaker
The fielddata circuit breaker limits the amount of heap used by loading field data into memory, preventing out-of-memory errors from large aggregation or sorting operations.
Question 3: During a quality review, you notice search latency spikes every 30 seconds. What default Elasticsearch behavior is most likely causing this?
- Snapshot scheduling
- Index refresh interval creating a new segment (Correct answer)
- ILM rollover check
- Replica sync operations
Correct answer: Index refresh interval creating a new segment
Elasticsearch's default refresh interval is 1 second, but periodic segment merges can cause latency spikes; a refresh interval set to 30s or segment merges happening at that cadence are common culprits.
Question 4: What does `index.number_of_replicas: 0` during a bulk reindex improve, and what quality risk does it introduce?
- Improves read throughput; risks write amplification
- Improves indexing speed; risks data loss if a node fails during reindex (Correct answer)
- Reduces heap usage; risks mapping conflicts
- Improves search accuracy; risks stale reads
Correct answer: Improves indexing speed; risks data loss if a node fails during reindex
Removing replicas during reindex significantly improves throughput by eliminating replica writes, but if a node fails before replicas are restored, that shard's data is permanently lost.
Question 5: Which Elasticsearch cat API provides the fastest way to identify shards that are currently being initialized or relocating across nodes?
- _cat/indices
- _cat/shards?v&h=index,shard,prirep,state,node (Correct answer)
- _cat/allocation
- _cat/health
Correct answer: _cat/shards?v&h=index,shard,prirep,state,node
`_cat/shards` with the state column shows each shard's current status (STARTED, INITIALIZING, RELOCATING, UNASSIGNED), making it the quickest way to track shard movement.
Question 6: When should you use `POST /<index>/_forcemerge?max_num_segments=1` as a quality assurance step?
- After every bulk indexing job to improve write performance
- On a read-only index (e.g., after ILM rollover) to optimize search performance and reduce resource usage (Correct answer)
- Before taking a snapshot to reduce repository size
- Immediately after increasing the replica count
Correct answer: On a read-only index (e.g., after ILM rollover) to optimize search performance and reduce resource usage
Force-merging to a single segment is safe and beneficial only on indices that are no longer being written to, as it maximizes search efficiency and eliminates tombstone overhead.
Question 7: What Elasticsearch diagnostic endpoint reveals whether search thread pool queues are saturated, indicating a performance quality issue?
- GET /_cluster/health
- GET /_nodes/stats/thread_pool (Correct answer)
- GET /_cat/segments
- GET /_stats/indexing
Correct answer: GET /_nodes/stats/thread_pool
`_nodes/stats/thread_pool` shows queue size, active threads, and rejected counts for each thread pool including search, bulk, and get, revealing saturation.
ElasticSearch Quality Control & Assurance 4
What is the correct way to verify that an Elasticsearch snapshot completed successfully and the data is restorable?