Reindex and Zero-Downtime Mapping Changes

The alias swap pattern

Because field types cannot change in place, mapping changes follow a pattern. (1) Applications always read and write through an alias, for example products pointing at products_v1. (2) Create products_v2 with the new mapping and analyzers. (3) Copy data with the _reindex API (for large indices run it with wait_for_completion=false and follow the task) or, often better, re-load from the source database. (4) Catch up writes that happened during the copy, for example by dual-writing to both indices during the migration or re-syncing changes since a timestamp. (5) Atomically move the alias to products_v2 in one _aliases call. (6) Keep v1 briefly for rollback, then delete it.

Reindex and swap the alias

Kibana Dev Tools console syntax; send the same requests with curl or a client library.

PUT /products_v2
{
  "mappings": {
    "properties": {
      "sku":  { "type": "keyword" },
      "name": { "type": "text", "fields": { "raw": { "type": "keyword" } } }
    }
  }
}

POST /_reindex?wait_for_completion=false
{
  "source": { "index": "products_v1" },
  "dest":   { "index": "products_v2" }
}
# -> { "task": "<node-id>:<task-number>" }

GET /_tasks/<node-id>:<task-number>

# atomic switch: both actions apply together
POST /_aliases
{
  "actions": [
    { "remove": { "index": "products_v1", "alias": "products" } },
    { "add":    { "index": "products_v2", "alias": "products", "is_write_index": true } }
  ]
}

Use an alias from day one

Even if you never plan to reindex, creating products_v1 behind a products alias costs nothing and turns a future migration from an outage into a routine change.

Quick check: Why is the alias switch done in a single _aliases request?

• It is faster to type
• The remove and add actions apply atomically, so clients never see no index
• Aliases can only be changed once
• It triggers an automatic reindex