[
https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634473#comment-13634473
]
Shawn Heisey commented on SOLR-4718:
------------------------------------
bq. What are the cons to always using ZK?
I missed this question from Erik when I was looking earlier.
The primary problem I see with always using zookeeper takes a little
explanation.
In a non-ZK install, making Solr fault tolerant for queries is fairly easy -
fire up another node and set up replication. That's not true fault tolerance,
as we all know.
Running the embedded zookeeper is something we don't recommend to people except
for single-server proof of concept setups. I don't even know if it's possible
to set up a fully functional fault-tolerant ensemble using the embedded
zookeeper.
Unfortunately, setting up a standalone ensemble is not trivial. It's not HARD,
but when you go from just running "java -jar start.jar" on a single server to a
real-world SolrCloud, either you have to start over or you end up performing
arcane rituals to migrate your existing setup.
In my opinion, it is a generally bad idea to have step-by-step documentation
that results in a setup that isn't fault tolerant. I have used a lot of open
source software with documentation like this. If documentation about adding
redundancy exists, it is often found in a completely different location as
reference material, not step-by-step instructions.
Our SolrCloud examples encourage setting up separate Solr JVMs on the same
server with the embedded zookeeper. Because that's the available
documentation, there are probably production installs set up this way. I think
that kind of setup should be in footnotes or appendices, and the main examples
should be multi-node, with clear instructions about how to make sure it won't
break when something fails. I'm not sure how to make it easy to set up
zookeeper. Cross-platform scripting is not easy, especially when one of those
platforms is Windows.
> Allow solr.xml to be stored in zookeeper
> ----------------------------------------
>
> Key: SOLR-4718
> URL: https://issues.apache.org/jira/browse/SOLR-4718
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Affects Versions: 4.3, 5.0
> Reporter: Erick Erickson
> Assignee: Erick Erickson
>
> So the near-final piece of this puzzle is to make solr.xml be storable in
> Zookeeper. Code-wise in terms of Solr, this doesn't look very difficult, I'm
> working on it now.
> More interesting is how to get the configuration into ZK in the first place,
> enhancements to ZkCli? Or boostrap-conf? Other? I'm punting on that for this
> patch.
> Second level is how to tell Solr to get the file from ZK. Some possibilities:
> 1> A system prop, -DzkSolrXmlPath=blah where blah is the path _on zk_ where
> the file is. Would require -DzkHost or -DzkRun as well.
> > pros - simple, I can wrap my head around it.
> - easy to script
> > cons - can't run multiple JVMs pointing to different files. Is this
> really a problem?
> 2> New solr.xml element. Something like:
> <solr>
> <solrcloud>
> <str name="zkHost">zkurl</str>
> <str name="zkSolrXmlPath">whatever</str>
> </solrcloud>
> <solr>
> Really, this form would hinge on the presence or absence of zkSolrXmlPath.
> If present, go up and look for the indicated solr.xml file on ZK. Any
> properties in the ZK version would overwrite anything in the local copy.
> NOTE: I'm really not very interested in supporting this as an option for
> old-style solr.xml unless it's _really_ easy. For instance, what if the local
> solr.xml is new-style and the one in ZK is old-style? Or vice-versa? Since
> old-style is going away, this doesn't seem like it's worth the effort.
> pros - No new mechanisms
> cons - once again requires that there be a solr.xml file on each client.
> Admittedly for installations that didn't care much about multiple JVMs, it
> could be a stock file that didn't change...
> For now, I'm going to just manually push solr.xml to ZK, then read it based
> on a sysprop. That'll get the structure in place while we debate. Not going
> to check this in until there's some consensus though.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
