Understanding Aliases


(Jason) #1

Hi!

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?