You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GET requests should be routed to the primary shard via the `preference` parameter, to prevent consistency issues. By default, Elasticsearch will round-robin GET requests between all available shards (primaries and replicas). Updates to a document are only consistent from the perspective of the thread updating the document, to all other threads it is possible to see a stale copy while the update is "in-flight" to one of the replicas.
By setting `preference=_primary`, the GET request is forced to route to the primary shard. Since the primary is the source of truth, it is guaranteed to always be consistent. You can [read more about preference here](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-preference.html).
Just as a note, when you add/remove aliases in a single operation, it is an atomic operation. E.g. if you do this:
```
POST /_aliases
{
"actions": [
{ "remove": { "index": "my_index_v1", "alias": "my_index" }},
{ "add": { "index": "my_index_v2", "alias": "my_index" }}
]
}
```
The alias swaps from `my_index_v1` to `my_index_v2` atomically. You can read more about swapping aliases [here](https://www.elastic.co/guide/en/elasticsearch/guide/current/index-aliases.html) and [here](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-aliases.html). If you were using this method and still seeing consistency issues, that's a bug...it'd be great if you can open a ticket! :)
0 commit comments