Reindex from Index/Remote Source, Slicing, Throttling, Conflict Handling, and Validation

Learning outcomes

AtlasMart needs to migrate atlasmart-products-v1 to a v2 mapping without pretending that reindex is a schema clone or a transaction. Reindex reads _source from a source snapshot and indexes documents into a separately prepared destination. The destination settings, mappings, shard count and analyzers must already be correct.

1. Prepare v2 explicitly

PUT atlasmart-products-v1
{
  "settings":{"number_of_shards":1,"number_of_replicas":0},
  "mappings":{"dynamic":"strict","properties":{
    "sku":{"type":"keyword"},
    "name":{"type":"text","fields":{"keyword":{"type":"keyword"}}},
    "category":{"type":"keyword"},
    "price":{"type":"scaled_float","scaling_factor":100},
    "available":{"type":"boolean"},
    "updated_at":{"type":"date"}
  }}
}

POST _bulk?refresh=true
{"index":{"_index":"atlasmart-products-v1","_id":"P-1001"}}
{"sku":"P-1001","name":"Wireless Noise Cancelling Headphones","category":"audio","price":199.99,"available":true,"updated_at":"2026-09-11T07:00:00Z"}
{"index":{"_index":"atlasmart-products-v1","_id":"P-1002"}}
{"sku":"P-1002","name":"USB-C Travel Charger","category":"power","price":49.95,"available":true,"updated_at":"2026-09-11T07:01:00Z"}
{"index":{"_index":"atlasmart-products-v1","_id":"P-1003"}}
{"sku":"P-1003","name":"Ergonomic Mechanical Keyboard","category":"input","price":129.00,"available":false,"updated_at":"2026-09-11T07:02:00Z"}

PUT atlasmart-products-v2
{
  "settings":{"number_of_shards":1,"number_of_replicas":0},
  "mappings":{"dynamic":"strict","properties":{
    "sku":{"type":"keyword"},
    "name":{"type":"text","analyzer":"standard","fields":{"keyword":{"type":"keyword"}}},
    "category":{"type":"keyword"},
    "price":{"type":"scaled_float","scaling_factor":100},
    "available":{"type":"boolean"},
    "updated_at":{"type":"date"},
    "schema_version":{"type":"keyword"}
  }}
}

Reindex does not copy the source index settings or templates into the destination. That is a feature: migrations should make the target contract explicit. It is also a common failure mode when teams create an empty destination with defaults and discover after cutover that shard count, analyzers or dynamic mapping differ.

2. Run a throttled local reindex

POST _reindex?wait_for_completion=false&requests_per_second=50&slices=1
{
  "source":{"index":"atlasmart-products-v1"},
  "dest":{"index":"atlasmart-products-v2"},
  "script":{
    "lang":"painless",
    "source":"ctx._source.schema_version = 'v2'"
  }
}

The response returns a task identifier. The lab uses conservative throttling only to make control visible; 50 is not a production recommendation. Pick rates from measured indexing headroom. Adding slices can increase parallelism but also increases source search work, destination indexing concurrency, merge pressure and disk growth.

GET _tasks?actions=*reindex*&detailed=true
GET _tasks/<node_id:task_id>
GET _nodes/stats/indices,fs,jvm
GET _cluster/health

3. Rethrottle rather than restart blindly

POST _reindex/<task_id>/_rethrottle?requests_per_second=20

Use task progress together with latency, CPU, JVM pressure, rejected work and disk headroom. If search p99 or recovery safety degrades, slow the job. If the cluster has demonstrated spare capacity, increase cautiously. The goal is completion inside the migration window without violating production SLOs—not maximum raw copy speed.

4. Conflicts are data, not noise

POST _reindex?conflicts=proceed&requests_per_second=25
{
  "source":{"index":"atlasmart-products-v1"},
  "dest":{"index":"atlasmart-products-v2","op_type":"create"}
}

op_type:create makes pre-existing destination IDs visible as conflicts rather than overwriting them. conflicts=proceed tells the operation to continue, not that the conflicting records are safe to ignore. Persist the conflict count and investigate the affected IDs. For deterministic migrations, stable IDs and an explicit change-data strategy are more important than simply suppressing errors.

5. Remote reindex adds a security/network boundary

POST _reindex
{
  "source":{
    "remote":{
      "host":"https://remote-search.example:9200",
      "username":"reindex-reader",
      "password":"${SECRET_FROM_SECURE_CONFIGURATION}"
    },
    "index":"atlasmart-products-v1",
    "size":500
  },
  "dest":{"index":"atlasmart-products-v2"}
}

Do not paste real credentials into shell history or committed request files. Remote reindex requires product-specific network/allowlist/security configuration, compatible TLS trust and privileges. Test cross-version support explicitly; Elasticsearch and OpenSearch are not generic remote-reindex substitutes for each other merely because their APIs share ancestry.

6. Validation must go beyond count equality

GET atlasmart-products-v1/_count
GET atlasmart-products-v2/_count

GET atlasmart-products-v1/_search
{"query":{"match":{"name":"wireless headphones"}},"size":10}

GET atlasmart-products-v2/_search
{"query":{"match":{"name":"wireless headphones"}},"size":10}

GET atlasmart-products-v2/_search
{
  "size":0,
  "aggs":{
    "by_category":{"terms":{"field":"category"}},
    "price_sum":{"sum":{"field":"price"}}
  }
}

Count equality proves only one dimension. Validate stable IDs, category and price aggregates, sample source hashes where practical, expected rejected documents, critical relevance fixtures, authorization behavior and write-path compatibility. If an analyzer changed, exact rank equality may be the wrong goal; compare against the judged expectations established in Chapter 07.

7. Deliberately wrong approach: copy at unlimited speed, cut over on count

This can saturate indexing/merge resources, miss concurrent writes and approve semantically broken data merely because counts match. Repair by pre-creating v2, choosing write coordination, throttling/slicing from measured headroom, monitoring tasks, validating content and search semantics, then switching aliases only after a documented go/no-go gate.

Production judgment

Estimate migration time from representative throughput, but preserve a safety factor for production load. Track source/destination counts over time, conflict/failure totals, task retries, throttled time, disk growth, merge pressure and search p95/p99. Cancel or rethrottle when safety boundaries are crossed. Keep source deletion outside the migration task and require an explicit post-cutover retention decision.

Summary and next step

You can now move existing documents under controlled load and prove destination quality. The next lesson applies the same task discipline to mass updates and deletes, where partial completion and rollback risk are even easier to underestimate.

Authoritative references

• Elastic aliases — Alias filters, routing, write-index behavior and alias management.
• Elastic update aliases API — Multi-action alias changes through POST /_aliases.
• Elastic rollover API — Manual rollover for data streams and index aliases; conditions and write-index semantics.
• Elastic reindex API — Reindex requirements, throttling, slicing, remote sources and destination preparation.
• Elastic update by query — Snapshot semantics, conflicts, slicing, throttling and task monitoring.
• Elastic task API — Task progress and status for long-running operations.
• OpenSearch aliases API — Atomic alias action sets, filters, routing and write-index behavior.
• OpenSearch rollover API — Rollover for aliases/data streams with age, docs and size conditions.
• OpenSearch reindex API — Local/remote reindex, slicing, throttling, background tasks and validation fields.
• OpenSearch update by query — Snapshot-based update-by-query, conflicts and partial completion semantics.
• OpenSearch delete by query — Snapshot-based deletion, conflicts and non-rollback behavior.
• OpenSearch cancel tasks — Cancellation behavior and cancellable task checks.