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

Sayan Das commented on SOLR-14648:
----------------------------------

I think #2 which [~ichattopadhyaya] suggested is the safest way to tackle this 
issue. We can have some flag which will take user consent of freshly 
replicating new set of indexes to PULL replicas. By default it should be other 
way around, in which it will check which pull replica have the latest set of 
index/segments (not sure if that is even possible or we can just skip this 
step?). Now when we know from where to replicate it will start reverse 
replication from "pseudo leader" PULL to leader elect TLOG.
Maybe we can give user the option from which PULL replica they want to 
replicate?

> Creating TLOG with pure multiple PULL replica, leading to 0 doc count
> ---------------------------------------------------------------------
>
>                 Key: SOLR-14648
>                 URL: https://issues.apache.org/jira/browse/SOLR-14648
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrCloud
>    Affects Versions: 8.3.1
>            Reporter: Sayan Das
>            Priority: Major
>
> With only PULL replica whenever we create a new TLOG as leader fresh 
> replication happens, resulting in flushing the older indexes from existing 
> PULL replicas
> Steps to replicate:
>  # Create 1 NRT or 1 TLOG replica as leader with multiple PULL replicas
>  # Index few documents and let it replicate in all the replicas
>  # Delete all the TLOG/NRT replica leaving PULL types
>  # Create a new TLOG/NRT as leader, once recovery completes it replaces all 
> the older indexes
> In ideal scenario it should have replicated from any one of the PULL replicas 
> that has latest indexes after that TLOG/NRT replica should be registered as 
> leader



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

Reply via email to