# Primary vs replica inconsistency in ES5.6 **URL:** \ **Category:** Elasticsearch\ **Created:** [September 25, 2020, 2:56am UTC](https://discuss.elastic.co/t/primary-vs-replica-inconsistency-in-es5-6/249893 "2020-09-25T02:56:55Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Priyanka\_Raju](https://avatars.discourse-cdn.com/v4/letter/p/f1d935/32.png) [@Priyanka\_Raju](https://discuss.elastic.co/u/Priyanka_Raju)\ **Post date:** [September 25, 2020, 2:56am UTC](https://discuss.elastic.co/t/primary-vs-replica-inconsistency-in-es5-6/249893/1 "2020-09-25T02:56:56Z")
Hi, I recently noticed that some of our queries returned inconsistent results, digging deep, I found that the query returned 0 results when the query was executed against one replica and returned results when executed against the other copies (we have 3 copies in total). I used the search API with `preference=_only_nodes:` to deduce the above. When I tried to use the `explain` API with `_source=true` and see what the response is, it looks like the document is present in all the replicas, but the output of the explain API returns `matched:false` against one copy and returns `matched:true` against another copies. The actual search query used is a `multi_match` query. Why would this happen? Is this a known issue/bug in Elasticsearch? I noticed that ES 5.6 had some issues where docs are missing in replica [https://github.com/elastic/elasticsearch/issues/19866](https://github.com/elastic/elasticsearch/issues/19866), is it related to the same? Elasticsearch version: 5.6 ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [September 28, 2020, 3:25am UTC](https://discuss.elastic.co/t/primary-vs-replica-inconsistency-in-es5-6/249893/2 "2020-09-28T03:25:40Z")
5.X is [EOL](https://www.elastic.co/support/eol), please upgrade ASAP 🙂 ---
**Author:** ![Steve\_Mushero](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/steve_mushero/32/22441_2.png) [@Steve\_Mushero](https://discuss.elastic.co/u/Steve_Mushero)\ **Post date:** [September 29, 2020, 3:45am UTC](https://discuss.elastic.co/t/primary-vs-replica-inconsistency-in-es5-6/249893/3 "2020-09-29T03:45:57Z")
How new is this data, i.e. just indexed a few seconds ago or much older, as certainly should be in sync if all the shards are refreshed, but they are not totally sync'd in the refresh period and in some other cases when there is limited indexing going on (refresh gets delayed). Can you find the doc ID and query by that, as that's more accurate than any text or normal search? As mentioned, it's an old version so hard to get help. ---
**Author:** ![Priyanka\_Raju](https://avatars.discourse-cdn.com/v4/letter/p/f1d935/32.png) [@Priyanka\_Raju](https://discuss.elastic.co/u/Priyanka_Raju)\ **Post date:** [September 30, 2020, 4:57am UTC](https://discuss.elastic.co/t/primary-vs-replica-inconsistency-in-es5-6/249893/4 "2020-09-30T04:57:30Z")
This data isn't newly indexed. It hasn't been updated for more than a month. I was able to find the doc by id in all replicas. The `phrase_prefix` match with `max_expansions` is the query that is not returning correct values. When I increased `max_expansions` to 100, instead of the default 50, all the replicas consistently returned the result. Is this the kind of inconsistency expected across different replicas? Updating the ES version - yes, we are planning to do that! But more concretely, is the above issue a known bug in 5.x and is fixed in later versions or is this something expected to happen with these shape of queries irrespective of the ES version? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [October 28, 2020, 4:57am UTC](https://discuss.elastic.co/t/primary-vs-replica-inconsistency-in-es5-6/249893/5 "2020-10-28T04:57:33Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.