[
https://issues.apache.org/jira/browse/SOLR-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494625#comment-17494625
]
David Smiley commented on SOLR-6237:
------------------------------------
I nearly forgot about this issue. At the time this was filed, there were only
one type of replicas that we now call NRT. Then SOLR-10233 for TLOG & PULL
replicas landed in May 2017. I think PULL replica types allow this issue to be
massively simplified because a PULL replica could be totally normal -- no
"shared" directory knowledge -- just replicate from the leader. Some trick
would be needed to use the same solrconfig.xml; perhaps the DirectoryFactory
could return a normal file system directory if the current replica is a PULL?
That's just a hack/straw-man; naturally it ought to be configurable somehow.
If the leader (of type TLOG) goes down, it could be replaced with
autoAddReplicas if it takes too long to re-appear. It could even be moved if
there was a planned node re-start. PULL replicas are eventually consistent
(ignore commits) so I could imagine a new option in which a commit is
optionally synchronous with ensuring the PULL replica gets up to date, and thus
wouldn't normally even poll. That'd be its own issue and it'd be useful in its
own right.
> An option to have only leaders write and replicas read when using a shared
> file system with SolrCloud.
> ------------------------------------------------------------------------------------------------------
>
> Key: SOLR-6237
> URL: https://issues.apache.org/jira/browse/SOLR-6237
> Project: Solr
> Issue Type: New Feature
> Components: hdfs, SolrCloud
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Major
> Attachments: 0001-unified.patch, SOLR-6237.patch, Unified Replication
> Design.pdf
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
