Alterar um mapping sem downtime (reindex + troca atômica de alias)

Comando

# 1) Target index with the new mapping (refresh off and replicas 0 for loading):
PUT musteri-v2
{
  "settings": { "number_of_shards": 1, "number_of_replicas": 0, "refresh_interval": "-1" },
  "mappings": { "properties": { "kod": { "type": "keyword" }, "adet": { "type": "long" } } }
}
# 2) Reindex in the background (tracked with the returned task id):
POST _reindex?wait_for_completion=false&slices=auto
{
  "source": { "index": "musteri-v1", "size": 1000 },
  "dest": { "index": "musteri-v2", "op_type": "create" },
  "conflicts": "proceed"
}
GET _tasks/<task_id>
# 3) Restore settings and compare document counts:
PUT musteri-v2/_settings
{
  "index": { "refresh_interval": null, "number_of_replicas": 1 }
}
POST musteri-v2/_refresh
GET _cat/indices/musteri-v1,musteri-v2?v&h=index,docs.count,pri.store.size
# 4) Switch the alias to the new index in one atomic operation:
POST _aliases
{
  "actions": [
    { "remove": { "index": "musteri-v1", "alias": "musteri" } },
    { "add": { "index": "musteri-v2", "alias": "musteri", "is_write_index": true } }
  ]
}

O que faz

Cria um índice com o novo mapping, copia os dados em background com reindex, compara as contagens de documentos e muda o alias usado pela aplicação para o novo índice em uma única operação atômica.

Quando usar

Quando o tipo de um campo existente precisa mudar (text -> keyword, integer -> long), um analyzer precisa mudar ou a quantidade de shards precisa ser redefinida; isso não pode ser feito no próprio índice existente.

Atenção

A aplicação precisa se conectar ao alias, não ao nome do índice; caso contrário, a troca exige um deploy. Novas escritas na origem durante o reindex não chegam ao destino: pare as escritas ou rode o reindex novamente com op_type create + conflicts proceed logo antes da troca para fechar a lacuna (updates e deletes não são levados dessa forma). O reindex gera carga de leitura na origem e de escrita no destino; limite com requests_per_second.