Understanding Aliases

(Jason) #1


I have an application that is talking to an index which I need to re-index with an additional shard. I understand that aliasing can help here, but I'm fuzzy on some stuff...

The index name is elastiflow-3.3.0-2018.10.06

Based on my understanding of Index Aliases, if I create an alias called elastiflow-3.3.0-2018.10.06-v1, it's going to do stuff in the backend to make any applications that used to talk to elastiflow-3.3.0-2018.10.06 now talk to elastiflow-3.3.0-2018.10.06-v1 instead.

At that point, Index Aliases and Zero Downtime suggests that I create the new index (which would include the appropriate settings for the additional shard) and then proceed to re-index elastiflow-3.3.0-2018.10.06-v1 to elastiflow-3.3.0-2018.10.06-v2. That part is fuzzy to me. Wouldn't I be better off to re-index elastiflow-3.3.0-2018.10.06 to elastiflow-3.3.0-2018.10.06-v2?

Once the re-indexing is done, I'm supposed to change the alias for elastiflow-3.3.0-2018.10.06 to point to elastiflow-3.3.0-2018.10.06-v2 now. The question at this point, is I think I now have 20GB of disk space that has been duplicated due to the reindexing of elastiflow-3.3.0-2018.10.06-v1 to elastiflow-3.3.0-2018.10.06-v2, but elastiflow-3.3.0-2018.10.06-v1 is an alias, so technically it's empty and a pointer to elastiflow-3.3.0-2018.10.06, which actually has all the original data. But, if I delete elastiflow-3.3.0-2018.10.06, don't I break the elastiflow-3.3.0-2018.10.06-v2 alias since it's an alias for elastiflow-3.3.0-2018.10.06 or does the alias voodoo take care of any references to the old index name, such that it is, in some way detached from the application so it can be deleted?

(system) #2

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