[
https://issues.apache.org/jira/browse/SOLR-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15641659#comment-15641659
]
Ishan Chattopadhyaya commented on SOLR-9689:
--------------------------------------------
In SOLR-5944, tlog entries can either be partial or full updates. Partial
updates would require that a corresponding full update be applied before it can
be applied. With concurrent processing of the updates during PeerSync, we need
to be very careful about DBQs in such a scenario. One way to deal with that is
to make sure that a DBQ is applied after all previous updates (updates with
version lesser than the DBQ update's version) have been applied, and no newer
update is applied until the DBQ has been applied.
> Process updates concurrently during PeerSync
> --------------------------------------------
>
> Key: SOLR-9689
> URL: https://issues.apache.org/jira/browse/SOLR-9689
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Pushkar Raste
> Attachments: SOLR-9689.patch, SOLR-9689.patch2
>
>
> This came up during discussion with [~shalinmangar]
> During {{PeerSync}}, updates are applied one a time by looping through the
> updates received from the leader. This is slow and could keep node in
> recovery for a long time if number of updates to apply were large.
> We can apply updates concurrently, this should be no different than what
> could happen during normal indexing (we can't really ensure that a replica
> will process updates in the same order as the leader or other replicas).
> There are few corner cases around dbq we should be careful about.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
