On Wed, Feb 5, 2014 at 6:33 PM, asanderson a.steven.ander...@gmail.comwrote:
Actually, I did indeed determine that for a few indexes there were
different doc counts between some shards and their replicas.
Under what circumstances could this happen, and what's the fastest/easiest
way to
This is something that shouldn't happen on a refreshed index. Could you
run a refresh on the indices that have different counts per shard:
curl -XPOST localhost:9200/${index_name}/_refresh
And then show two responses to
curl http://localhost:9200/${index_name}/_search
that return
Take a look at the 'preference' property of the search request body. If you
use the user's session id as a custom string, it should prevent the jumping
around of values.
Docs:
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-preference.html
Jörg recently
We are definitely not performing any updates in parallel nor do we have any
TTLs. Even if we did though, why would the counts alternate on subsequent
requests?
As far as plugins, we are using the analysis-phonetic plugin but
considering this is a match_all query, I wouldn't think it would be a
It shouldn't happen if you are not performing updates in parallel and don't
have documents with a TTL. Maybe you have a plugin that persists data in an
index that is taken into account when summing all hits in all indices?
(would be helpful to know the index which has changing counts).
On Wed,
Sorry, I thought you said that document counts were changing but it's
actually more than that it's going back and forth to 2 different values
(didn't get that).
This is indeed unexpected. You could try to run
curl http://localhost:9200/_aliases
to make sure all your shards have the same number
Actually, I did indeed determine that for a few indexes there were
different doc counts between some shards and their replicas.
Under what circumstances could this happen, and what's the fastest/easiest
way to correct this situation?
On Wednesday, February 5, 2014 12:02:20 PM UTC-5, Adrien
