You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by "Buttler, David" <bu...@llnl.gov> on 2012/08/21 22:46:08 UTC
Co-existing solr cloud installations
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
Posted by Lance Norskog <go...@gmail.com>.
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 <ma...@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 <bu...@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
goksron@gmail.com
RE: Co-existing solr cloud installations
Posted by "Buttler, David" <bu...@llnl.gov>.
This is really nice. Thanks for pointing it out.
Dave
-----Original Message-----
From: Mark Miller [mailto:markrmiller@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 <bu...@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
Posted by Mark Miller <ma...@gmail.com>.
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 <bu...@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
>