[
https://issues.apache.org/jira/browse/SOLR-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051283#comment-15051283
]
Mark Miller commented on SOLR-8372:
-----------------------------------
bq. Both use the REQUESTAPPLYUPDATES
Ah, was looking for a cmd like that but did not see it.
bq. Are there other scenarios where this wouldn't be the right thing to do?
Doesn't seem so then?
Only thing I can think of is, what about the async nature of those core admin
buffer calls - any chance of those overlapping with recovery strategy buffer
calls? And if so, would that matter with this change?
> Canceled recovery can lead to data loss
> ---------------------------------------
>
> Key: SOLR-8372
> URL: https://issues.apache.org/jira/browse/SOLR-8372
> Project: Solr
> Issue Type: Bug
> Reporter: Yonik Seeley
>
> A recovery via index replication tells the update log to start buffering
> updates. If that recovery is canceled for whatever reason by the replica,
> the RecoveryStrategy calls ulog.dropBufferedUpdates() which stops buffering
> and places the UpdateLog back in active mode. If updates come from the
> leader after this point (and before ReplicationStrategy retries recovery),
> the update will be processed as normal and added to the transaction log. If
> the server is bounced, those last updates to the transaction log look normal
> (no FLAG_GAP) and can be used to determine who is more up to date.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
