Re: Co-existing solr cloud installations
ZK has a 'chroot' feature (named after the Unix multi-tenancy feature). http://zookeeper.apache.org/doc/r3.2.2/zookeeperProgrammers.html#ch_zkSessions https://issues.apache.org/jira/browse/ZOOKEEPER-237 The last I heard, this feature could work for making a single ZK cluster support multiple SolrCloud clusters. Has it been proofed out? On Tue, Aug 21, 2012 at 8:22 PM, Mark Miller markrmil...@gmail.com wrote: You can use a connect string of host:port/path to 'chroot' a path. I think currently you have to manually create the path first though. See the ZkCli tool (doc'd on SolrCloud wiki) for a simple way to do that. I keep meaning to look into auto making it if it doesn't exist, but have not gotten to it. - Mark On Tue, Aug 21, 2012 at 4:46 PM, Buttler, David buttl...@llnl.gov wrote: Hi all, I would like to use a single zookeeper cluster to manage multiple Solr cloud installations. However, the current design of how Solr uses zookeeper seems to preclude that. Have I missed a configuration option to set a zookeeper prefix for all of a Solr cloud configuration directories? If I look at the zookeeper data it looks like: * /clusterstate.json * /collections * /configs * /live_nodes * /overseer * /overseer_elect * /zookeeper Is there a reason not to put all of these nodes under some user-configurable higher-level node, such as /solr4? It could have a reasonable default value to make it just as easy to find as /. My current issue is that I have an old Solr cloud instance from back in the Solr 1.5 days, and I don't expect that the new version and the old version will play nice. Thanks, Dave -- Lance Norskog goks...@gmail.com
RE: Co-existing solr cloud installations
This is really nice. Thanks for pointing it out. Dave -Original Message- From: Mark Miller [mailto:markrmil...@gmail.com] Sent: Tuesday, August 21, 2012 8:23 PM To: solr-user@lucene.apache.org Subject: Re: Co-existing solr cloud installations You can use a connect string of host:port/path to 'chroot' a path. I think currently you have to manually create the path first though. See the ZkCli tool (doc'd on SolrCloud wiki) for a simple way to do that. I keep meaning to look into auto making it if it doesn't exist, but have not gotten to it. - Mark On Tue, Aug 21, 2012 at 4:46 PM, Buttler, David buttl...@llnl.gov wrote: Hi all, I would like to use a single zookeeper cluster to manage multiple Solr cloud installations. However, the current design of how Solr uses zookeeper seems to preclude that. Have I missed a configuration option to set a zookeeper prefix for all of a Solr cloud configuration directories? If I look at the zookeeper data it looks like: * /clusterstate.json * /collections * /configs * /live_nodes * /overseer * /overseer_elect * /zookeeper Is there a reason not to put all of these nodes under some user-configurable higher-level node, such as /solr4? It could have a reasonable default value to make it just as easy to find as /. My current issue is that I have an old Solr cloud instance from back in the Solr 1.5 days, and I don't expect that the new version and the old version will play nice. Thanks, Dave
Re: Co-existing solr cloud installations
You can use a connect string of host:port/path to 'chroot' a path. I think currently you have to manually create the path first though. See the ZkCli tool (doc'd on SolrCloud wiki) for a simple way to do that. I keep meaning to look into auto making it if it doesn't exist, but have not gotten to it. - Mark On Tue, Aug 21, 2012 at 4:46 PM, Buttler, David buttl...@llnl.gov wrote: Hi all, I would like to use a single zookeeper cluster to manage multiple Solr cloud installations. However, the current design of how Solr uses zookeeper seems to preclude that. Have I missed a configuration option to set a zookeeper prefix for all of a Solr cloud configuration directories? If I look at the zookeeper data it looks like: * /clusterstate.json * /collections * /configs * /live_nodes * /overseer * /overseer_elect * /zookeeper Is there a reason not to put all of these nodes under some user-configurable higher-level node, such as /solr4? It could have a reasonable default value to make it just as easy to find as /. My current issue is that I have an old Solr cloud instance from back in the Solr 1.5 days, and I don't expect that the new version and the old version will play nice. Thanks, Dave
