What does Elasticsearch's _split API require of the source index, and how does _shrink differ?

## Both APIs make a new index `POST /source/_split/target` and `POST /source/_shrink/target` never modify the source in place. They create a new index with a different primary shard count and populate it from the source's existing Lucene segment files — using hard links when the source and target data paths are on the same filesystem, and copying otherwise. Because the source's data must not change while that happens, the first step in both flows is the same: make the source read-only. ``` PUT /logs-000042/_settings { "settings": { "index.blocks.write": true } } ``` That block allows reads and metadata changes but rejects indexing. Note the practical consequence: for an index still receiving writes, neither API is a live operation. That is one reason the usual answer for append-only data is to roll over to a correctly sized new index instead. ## _split — more primaries Constraints: - The target primary count must be a **multiple** of the source count (3 → 6, 3 → 9, 1 → anything). - It must be compatible with the source's `index.number_of_routing_shards`, a final setting chosen at index creation. This is the real ceiling: routing shards define the granularity that Elasticsearch's routing formula can be re-divided at, so an index can only be split into counts that the routing-shard configuration supports. If you know an index may need to grow, set `number_of_routing_shards` explicitly at creation. - The source must be read-only and healthy. Mechanically, the target's shards hard-link (or copy) the source segments, then Elasticsearch re-hashes every document and deletes the ones that belong to a different target shard, then recovers the target index. Nothing is re-analysed, so it is much cheaper than a reindex — but it does temporarily use extra disk, and the deleted documents remain in the segments until merges reclaim them, so a force merge afterwards is common. ## _shrink — fewer primaries Constraints: - The target primary count must be a **factor** of the source count (8 → 4, 8 → 2, 8 → 1). Shrinking to 1 is always legal. - Cluster health must be **green**. - A copy of **every** shard of the source must be on a single node, because the target shard is built from those local segment files. You arrange that with allocation filtering: ``` PUT /logs-000042/_settings { "settings": { "index.number_of_replicas": 0, "index.routing.allocation.require._name": "data-node-7", "index.blocks.write": true } } ``` Wait for relocation to finish (health green again), then call `POST /logs-000042/_shrink/logs-000042-shrunk` with the target settings, typically `index.number_of_shards: 1`, `index.number_of_replicas: 1` and a cleared allocation requirement. Because the operation is essentially a local hard-link of segments plus a recovery, it is fast relative to reindexing the same data. ## Afterwards Neither API touches aliases for you. The full flow is: create the target, wait for it to go green, re-point any read aliases (and the write alias, if applicable) from source to target, remove the write block on the target if you copied it, verify document counts, then delete the source. Doing the alias swap atomically with a single `_aliases` request avoids a window where searches see neither index or both. ## When to reach for which - **`_shrink`** is the workhorse for time-series data: yesterday's index is no longer written to, so shrinking it to one primary and force-merging reduces shard count and improves compression on cold data. This is precisely the shape that index lifecycle tooling automates. - **`_split`** is for the case where an index was created far too small and now holds shards well beyond the tens-of-gigabytes range while still needing to grow. It is less common, because it requires a write block and the routing-shard ceiling was fixed at creation. - **Reindex** remains the general fallback: it has no shard-count arithmetic constraints, can change mappings and analysis at the same time, and can run while the source keeps serving reads — but it re-analyses every document and is the most expensive option. ## Interview framing A strong answer names the arithmetic constraint for each (multiple versus factor), the shared read-only requirement, and the shrink-specific "all shards on one node, cluster green" prerequisite — and then notes that both produce a new index, so the alias swap is part of the plan, not an afterthought.