[jira] [Updated] (SOLR-7625) Version bucket seed not updated after new index is installed on a replica

["Timothy Potter (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Timothy Potter updated SOLR-7625:
---------------------------------
    Attachment: SOLR-7625.patch

Here's a patch that addresses this issue. The key part of the fix is in RecoveryStrategy where it will call {{core.seedVersionBuckets()}} after recovery is successful if the tlog wasn't replayed; if the tlog was replayed, then the version buckets are already updated as part of the replay process. So this patch catches the problem where no replay happens, but the underlying index still gets updated (usually by downloading a new index dir from the leader).

For now, I had to infuse a test for this into the HttpPartitionTest because I need a replica to go into recovery to verify that that version bucket max is updated after recovery succeeds.

All tests pass on trunk with this patch applied.

> Version bucket seed not updated after new index is installed on a replica
> -------------------------------------------------------------------------
>
>                 Key: SOLR-7625
>                 URL: https://issues.apache.org/jira/browse/SOLR-7625
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>    Affects Versions: 5.2
>            Reporter: Timothy Potter
>            Assignee: Timothy Potter
>            Priority: Blocker
>             Fix For: 5.2
>
>         Attachments: SOLR-7625.patch
>
>
> This is related to SOLR-7332 ... I used to set the highest value on the version buckets based on a lookup to the index whenever a firstSearcher event fired, but that led to reentrant lock issues (see SOLR-7587), so I moved that version seeding code into the SolrCore constructor.
> While working on SOLR-4506, I just realized that if a core has to pull index files from the leader to recover, then the version bucket doesn't get updated once the new index files are pulled over. In other words, the code seeds the version buckets during core init, but if the underlying index changes due to being too far out-of-date, then the version buckets are never updated once the new index is in place. The risk is that if bucket versions are seeded with a value that is too low, then it can lead to correctness issues with versioned updates.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org