3 ms·
That still doesn't guarantee that a consecutive read is gonna get the last state. Welcome to the wonderful world of "eventual consistency".
by kn7 8y ago
That still doesn't guarantee that a consecutive read is gonna get the last state. Welcome to the wonderful world of "eventual consistency".
- manigandham 8y agoHow so? That's the entire point of the feature. What else is there to update?
- IggleSniggle 8y agoIt guarantees that all replications will report state in sync with each other on search, not that the last reported state is the actual current state of the index.
- manigandham 8y agoAs the numerous comments here and the documentation states, the refresh flag on your insert/update will ensure that changed data in that request is consistent for queries after. Where did you get the behavior you described? Are you sure you're not confusing this for the separate refresh command itself? That is not attached to any particular insert/update.
- atombender 8y agoThe "refresh=wait_for" [1] index setting does guarantee that a subsequent read will get the data. It causes all shards to refresh: Refresh the relevant primary and replica shards (not the whole index) immediately after the operation occurs, so that the updated document appears in search results immediately There's also the "wait_for_active_shards=<n>" setting, which merely asks to wait until n shards have written the changes. [1] https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-refresh.html https://www.elastic.co/guide/en/elasticsearch/reference/curr...