Hi,
I am just trying to understand the usage of index-alias. Below is the process i am thinking of. Let me know if i am going wrong anywhere.
Let’s say i want to have index A with fields a and b. Now, i want to remove field b from index A.
Process 1
Application is using index A.
Now create index-alias A_alias which is pointing to index A.
Point application to A_alias instead of A.
Create index A_dash where i am removing field b from definition of A.
Point index-alias A_alias to A_dash.
Remove index A.
Keep application to point to index-alias A_alias.
OR
Process 2
Application is using index A.
Now create index-alias A_alias which is pointing to index A.
Point application to A_alias instead of A.
Update index A where i am removing field b from definition of A.
Keep application to point to index-alias A_alias.
Which process is correct? If process 1 is correct, it means clients need to maintain the index switching. And if process 2 is correct, it means Couchbase internally doing process 1.
However, if index switching is happening,
Do we need to increase memory quota for search service during that time? OR Cluster will manage on its own? Will there be any resource deficiency in that case because live traffic is still going on?
How to rename the index A_dash back to A?
Can we use index-alias name in flex indexes as well?
Process 1 looks closer.
The index-alias should be created along with the index and the applications should always refer to the index-alias from the beginning.
Flipping the index-alias to another newer index is the job of the administrator as of now. They could do that in a flip second without additional resource overheads.
In the index listing page of search service, users can edit the index-alias from UI to change the underlying physical indexes. This is resource lightweight. And no resource provisioning is needed.
Once the flipping is done, you may delete the older index too. You may confirm this by monitoring the stats on the newer index.
Flex/N1QL has very strong syntax and hence doesn’t allow index-alias today as an alias can cover indexes across buckets.
Yea… If your former plan B of fetching documents from KV after obtaining the document IDs from FTS could be an alternative to using N1QL if that fits with your other application requirements.
With aliases, no need to rename the newer index back to older index name as the index names are hidden from outside world/applications. All the users of FTS should only be knowing/using index aliases. Actual index name could be anything hidden under it and could be created/dropped upon requirements…
Alias gets edited/updated by the admin to flip the underlying index(es) in a sub second operation.