Elastic Search:Update of existing Record (which has custom routing param set) results in duplicate record, if custom routing is not set during update

Env Details:
Elastic Search version 7.8.1
routing param is an optional in Index settings.

As per Elasticsearch docs - _routing field | Elasticsearch Guide [8.6] | Elastic

When indexing documents specifying a custom _routing, the uniqueness of the _id is not guaranteed across all of the shards in the index. In fact, documents with the same _id might end up on different shards if indexed with different _routing values.

We have landed up in same scenario where earlier we were using custom routing param(let's say customerId). And for some reason we need to remove custom routing now. Which means now docId will be used as default routing param. This is creating duplicate record with same id across different shard during Index operation. Earlier it used to (before removing custom routing) it resulted in update of record (expected)

I am thinking of following approaches to come out of this, please advise if you have better approach to suggest, key here is to AVOID DOWNTIME.

Approach 1: As we receive the update request, let duplicate record get created. Once record without custom routing gets created, issue a delete request for a record with custom routing.

CONS: If there is no update on records, then all those records will linger around with custom routing, we want to avoid this as this might results in unforeseen scenario in future.

Approach 2 We use Re-Index API to migrate data to new index (turning off custom routing during migration). Application will use new index after successful migration.

CONS: Some of our Indexes are huge, they take 12 hrs+ for re-index operation, and since Elasticsearch re-index API will not migrate the newer records created between this 12hr window, as it uses snapshot mechanism. This needs a downtime approach.

Please suggest alternative if you have faced this before.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.