Index aliasing lets us version and swap indices without downtime, which could improve the rebuild path.
This is the "swap" operation that would be used for upgrade_index.
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-aliases.html
-XPOST localhost:9200/_aliases
{
"actions": [
{ "remove": {
"alias": "parsely-1hour-2014.09",
"index": "v1_parsely-1hour-2014.09"
}},
{ "add": {
"alias": "parsely-1hour-2014.09",
"index": "v2_parsely-1hour-2014.09"
}}
]
}
So maybe create_index gets modfied to know about aliases and then add a command like upgrade_index to go from.
python src/cli_index.py create_index --ns casterisk --version v3
python src/cli_index.py upgrade_index --ns casterisk --version v3
Imagine an index alias with three version:
parsely-1hour-2014.09 =>
v1_parsely-1hour-2014.09 *
v2_parsely-1hour-2014.09
v3_parsely-1hour-2014.09
The * one is the current index version, but two other versions were rebuilt. We decide v2 sucks, so we delete it. But then we decide to upgrade to v3 once we realized the data is good.
Here is how it'll work:
- Create an index with the next version number before indexing into it.
- If version is v1, create alias (since it won't exist yet)
- Add a utility to swap all aliases to a specified version