With the alias and reindex operations of ES, data migration of services without downtime can be realized in some business scenarios.

The premise is that data reads and writes depend on the alias of the index, not the specific index.

As shown below:

Write operations rely on the write_alias alias and read operations rely on the read_alias alias.

When data migration is required,

Step 1: Create a new index, Index_version_v2, as required.

Step 2: Delete the association between write_alias and Index_version_v1, and establish the association between write_alias and Index_version_v2.

The following operations are atomic operations.

POST /_aliases
{
    "actions" : [
        { "remove" : { "index" : "Index_version_v1", "alias" : "write_alias" } },
        { "add" : { "index" : "Index_version_v2", "alias" : "write_alias" } }
    ]
}
Copy the code

Step 3: Rebuild the data from index_version_v1 to index_version_v2 using the ES reindex operation.

  POST _reindex
    {
      "source": {
        "index": "Index_version_v1"
      },
      "dest": {
        "index": "Index_version_v2"
      }
    }
Copy the code

Step 4: Delete the association between read_alias and Index_version_v2, and establish the association between read_alias and Index_version_v2.

POST /_aliases
{
    "actions" : [
        { "remove" : { "index" : "Index_version_v1", "alias" : "read_alias" } },
        { "add" : { "index" : "Index_version_v2", "alias" : "read_alias" } }
    ]
}
Copy the code

Possible problems:

When the Index_version_v2 data is not reindex completed, Index_version_v1 needs to be relied on to provide data reading operations, resulting in data inconsistency. This area requires a business-specific assessment.