Write consistency in elasticsearch is quite different to what has been
described here. You can think of it as a check done before indexing, to
make sure that enough copies of the data are available. It doesn't have
anything to do with when the response is returned and only affects whether
the write operation is accepted or not in the first place.
On the other hand, the replication (sync by default) affects when the
response is returned: by default after all copies have the document
indexed, only after the primary otherwise (async).
Using write consistency in the described usecase doesn't make a difference
in terms of making the document available for get, used internally by the
update API. In fact, the get API works in real-time, as it can retrieve the
documents from the transaction log if a refresh has not happened yet in the
lucene index. That means that when the index operation returns, using the
default sync replication, all copies (primary + replicas) have the document
at least in the transaction log, which can be retrieved using the get API,
no refresh needed.
Interesting that in some cases you got 404, that sounds weird, are you sure
the update happens after the previous operation returned?
Also, using the update API the document is always retrieved from the
primary shard, modified and reindexed there (+ replication afterwards),
thus you could potentially set the replication to async without running
into problems when it comes to updating the document using the update API.
As for the 409, that's a version conflict, meaning that there probably are
multiple updates done to the same document, you might want to tweak
retry_on_conflict to allow for retries when a conflict is found.
On Tuesday, January 21, 2014 11:34:06 PM UTC+1, Jörg Prante wrote:
Write consistency = ALL returns to the client after all nodes that hold
shards have responded, but that does not necessarily mean they are
available for "get" by other clients (update is using get operation to
retrieve the document).
If you want causality in your data writes and reads, you must use the
refresh operation (with all the negative impacts on performance).
Jörg
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/b1f1b863-980f-4bcf-aa50-f92814f8bb71%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.