[ 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