[
https://issues.apache.org/jira/browse/SOLR-14778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188032#comment-17188032
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14778:
------------------------------------------------------
I didn't know disabling the update log for SolrCloud use cases would work at
all. How does recovery work? These are the first line of the recovery code:
{code:java}
UpdateLog ulog;
ulog = core.getUpdateHandler().getUpdateLog();
if (ulog == null) {
SolrException.log(log, "No UpdateLog found - cannot recover.");
recoveryFailed(core, zkController, baseUrl, coreZkNodeName,
this.coreDescriptor);
return;
}
{code}
Or is it for the single-replica cases only?
> Disabling UpdateLog leads to silently lost updates
> --------------------------------------------------
>
> Key: SOLR-14778
> URL: https://issues.apache.org/jira/browse/SOLR-14778
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud, update
> Affects Versions: 8.6.1
> Reporter: Megan Carey
> Priority: Minor
>
> Solr currently "supports" disabling the UpdateLog, though it is "required"
> for NRT replicas (per the
> [docs|https://lucene.apache.org/solr/guide/8_6/updatehandlers-in-solrconfig.html#transaction-log]).
> However, when the update log is disabled and a replica is in BUFFERING state
> (e.g. during MigrateCmd or SplitShardCmd), updates are *lost silently*. While
> most users will likely never consider disabling the updateLog, it seems
> pertinent to provide a better support option.
> Options as discussed in [ASF
> Slack|https://the-asf.slack.com/archives/CEKUCUNE9/p1598373062262300]:
> # No longer support disabling the updateLog as it is considered an integral
> feature in SolrCloud. This might be undesirable for use cases where some data
> loss is acceptable and the updateLog takes up too much space.
> # Improve Solr documentation to explicitly outline the risks of disabling
> the updateLog.
> # Add logging to indicate when an update is swallowed in this state.
> # _My preferred option:_ Support disabling the updateLog by providing
> additional replica states besides BUFFERING, so that there is no data loss
> when updateLog is disabled and replica goes offline for an operation like
> split. Some ideas:
> ## REJECTING: Fail updates so that the client can retry again once the
> operation is complete.
> ## BLOCKING: Stall update until operation is complete, and then execute
> update.
> Feedback is welcome; once we establish a path forward I'd be happy to pick it
> up. If others are interested I can document my findings as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
