[ 
https://issues.apache.org/jira/browse/SOLR-9922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15803441#comment-15803441
 ] 

Mark Miller commented on SOLR-9922:
-----------------------------------

I guess I don't understand "But I think when user update the Solr, their node 
must be in active state"

Or really, the whole statement "But I think when user update the Solr, their 
node must be in active state, so the the new version won't have to read old 
tlog."

The way I read it, you are saying, when you update Solr, the new version won't 
have to read the old tlog". So I'm mentioning where that could easily happen. 
But you have answered there is no problem in UpdateLog.recoverFromLog. I have 
not looked at the patch, so I assume I don't understand the quoted sentence 
fully.

> Write buffering updates to another tlog
> ---------------------------------------
>
>                 Key: SOLR-9922
>                 URL: https://issues.apache.org/jira/browse/SOLR-9922
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Cao Manh Dat
>         Attachments: SOLR-9922.patch, SOLR-9922.patch, SOLR-9922.patch
>
>
> Currently, we write buffering logs to current tlog and not apply that updates 
> to index. Then we rely on replay log to apply that updates to index. But at 
> the same time there are some updates also write to current tlog and applied 
> to the index. 
> For example, during peersync, if new updates come to replica we will end up 
> with this tlog
> tlog : old1, new1, new2, old2, new3, old3
> old updates belong to peersync, and these updates are applied to the index.
> new updates belong to buffering updates, and these updates are not applied to 
> the index.
> But writing all the updates to same current tlog make code base very complex. 
> We should write buffering updates to another tlog file.
> By doing this, it will help our code base simpler. It also makes replica 
> recovery for SOLR-9835 more easier. Because after peersync success we can 
> copy new updates from temporary file to current tlog, for example
> tlog : old1, old2, old3
> temporary tlog : new1, new2, new3
> -->
> tlog : old1, old2, old3, new1, new2, new3



--
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

Reply via email to