[
https://issues.apache.org/jira/browse/SOLR-14778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188743#comment-17188743
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14778:
------------------------------------------------------
Got it, I said that because it seemed from the description of the jira (I
didn't look at the Slack conversation) that it was something that some commands
would have issues with, but regular recovery currently would suffer it too,
this means, every Solr cluster in cloud mode would be hit unless they have a
single "indexing" replica (NRT or TLOG) per shard.
bq. If there is no updateLog, then recovery "could" work via replication,
naturally.
I think this could be tricky. Thinking in a case like you described (all
updates are batches + commits), a recovery could only succeed if there are no
updates on the leader while the replica is recovering because there would be no
buffering. I guess maybe an option could be to allow update log only for
buffering? may complicate the logic a bit so we'd need to balance it against
the potential benefits, right? is it the extra disk write of the tlog?
bq. REJECTING: Fail updates so that the client can retry again once the
operation is complete.
I think something like this could work (as I said, I think recoveries would
fail on updates during the recovery time), Although I don't think I'd model it
as replica state, since it would be the leader that needs to start rejecting
updates because one or more replicas are recovering (or doing some operation
that requires tlog). I'm thinking it could be modeled as a different
RecoveryStrategy where the the leader stops accepting updates when a replica
wants to start recovering? something similar would have to be triggered by
those commands that [~megancarey] was mentioning.
> 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
