There are several possibilities:
1> you simply have some process incorrectly updating documents.
2> you’ve changed your schema sometime without completely deleting your old
index and re-indexing all documents from scratch. I recommend in fact indexing
into a new collection and using collection aliasing if you can’t delete and
recreate the collection before re-indexing. There’s some support for this idea
because you say that the doc in question not only changes one way, but then
changes back mysteriously. So seg1 (old def) merges with seg2 (new def) into
seg10 using the old def because merging saw seg1 first. Then sometime later
seg3 (new def) merges with seg10 and the data mysteriously comes back because
that merge uses seg3 (new def) as a template for how the index “should” look.
But I’ve never heard of Solr (well, Lucene actually) doing this by itself, and
I have heard of the merging process doing “interesting” stuff with segments
created with changed schema definitions.
Best,
Erick
> On Sep 28, 2020, at 8:26 AM, Mr Havercamp <mrhaverc...@gmail.com> wrote:
>
> Hi,
>
> We're seeing strange behaviour when records have been committed. It doesn't
> happen all the time but enough that the index is very inconsistent.
>
> What happens:
>
> 1. We commit a doc to Solr,
> 2. The doc shows in the search results,
> 3. Later (may be immediate, may take minutes, may take hours), the same
> document is emptied of all data except version and id.
>
> We have custom scripts which add to the index but even without them being
> executed we see records being updated in this way.
>
> For example committing:
>
> { id: talk.1234, from: "me", to: "you", "content": "some content", title:
> "some title"}
>
> will suddenly end up as after an initial successful search:
>
> { id: talk.1234, version: 1234}
>
> Not sure how to proceed on debugging this issue. It seems to settle in
> after Solr has been running for a while but can just as quickly rectify
> itself.
>
> At a loss how to debug and proceed.
>
> Any help much appreciated.
