Deprecating _primary preference makes getting consistent results impossible(?)

[bra-fsn]

Elasticsearch up to 6.x has a preference setting (for eg. get and search operations) named _primary.
According to the docs this makes the query to run on the primary shard:
" The operation will go and be executed only on the primary shards. "

On master (7.x) this setting has disappeared (on 6.x it's deprecated) and for the doc API only _local remained.

This makes it impossible to use the doc (and search) API to get consistent results. A subsequent query could return stale data, which may be even true if a custom preference value is used, because it just hashes the client to a given shard, which may be yet to be updated (while asking the primary would return correct result). Two different clients could get two different results for the same query in the same time this way (or given that all clients use the same custom preference could all see the same stale data).

One could argue that using wait_for_active_shards is the solution here, but even if it's working correctly in this manner (ie: all replicas and the primary are updated atomically from the PoV of the client, which I guess is not true), it would require that all of the shards are always available for writes, which makes replication somewhat useless, or at least much less useful.

Given all of these, I would like to ask you to restore the _primary option for preference.

[elasticmachine]

Pinging @elastic/es-search-aggs

[elasticmachine]

Pinging @elastic/es-distributed

[colings86]

@bra-fsn could you explain a bit about your use case and why you only want to retrieve results from the primary?

If the use case is down to wanting every client to see the exact same view of the data and not have stale reads I think you'd have a hard time achieving this even with _primary. This is because of two things:

• Shard failure - A primary shard failure will permanently change the primary and in the case where not all shard copies are up to date you may still see stale data anyway since the new primary becomes the source of truth. If the new primary is up to date with the failed one then you would be ok but this is the same as using those shard copies in your requests anyway?
• Refreshes - If your index is changing then your clients may see different views of the data anyway depending on whether a refresh happened between one being serviced and the other being serviced

I also wonder why you do not consider custom preference an option since if you wanted to replicate the behaviour of _primary and have all requests form all clients go to the same shard copies (assuming no shard failures) then you could use the same preference value for all requests across all your clients instead of creating a preference value per client or session? This would not guarantee the primary is used but would mean that all requests from all clients should use the same shard copies (ignoring shard failures) which seems to be what you are after?

[DaveCTurner]

What @colings86 said is true: using _primary gives no stronger consistency guarantees than using a custom preference.

it just hashes the client to a given shard, which may be yet to be updated (while asking the primary would return correct result).

It is not the case that the primary always serves all acknowledged writes, because it might not have refreshed. It is also not the case that replicas lag behind the primary like this: writes are only acknowledged once written to all copies, not just to the primary.

[bleskes]

we discussed it on fix it friday. The main use case for preferences are data locality (for attribute based preferences) and more efficient use of shard caches (where the custom preference value sends requests to the same shard where caches are potentially hot). We should update the docs to better reflect that and also to clarify that this is why the _primary_* options were deprecated. They help with neither options.