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 Jamie Johnson <je...@gmail.com> on 2011/10/03 23:52:56 UTC
Determining master/slave from ZK in SolrCloud
Is it possible to determine if a solr instance is a master or a slave
in replication terms based on the information that is placed in ZK in
SolrCloud?
Re: Determining master/slave from ZK in SolrCloud
Posted by Jamie Johnson <je...@gmail.com>.
I'm putting this out there for comment.
Right now I'm in ZKControllers and changed register as follows:
public void register(SolrCore core, boolean forcePropsUpdate) throws
IOException,....
and at line 479 I've added this
SolrRequestHandler requestHandler = core.getRequestHandler("/replication");
boolean master = false;
if(requestHandler != null && requestHandler instanceof ReplicationHandler){
ReplicationHandler replicationHandler = (ReplicationHandler)requestHandler;
master = replicationHandler.isMaster();
}
props.put("replication.master", master);
I also modified CoreContainer and ReplicationHandler to support what I
have above. Does this seem a reasonable way to approach this?
Also to provide some history, I need this so I can programatically
determine which servers are masters and slaves and subsequently which
should be written to (for updates) and which should be queried.
On Tue, Oct 4, 2011 at 10:26 AM, Jamie Johnson <je...@gmail.com> wrote:
> Ok, so I am pretty sure this information is not available. What is
> the most appropriate way to add information like this to ZK? I can
> obviously look for the system properties enable.master and
> enable.slave, but that won't be fool proof since someone could put
> this in the config file instead and not as a system property. Is
> there a way to determine this quickly programatically without having
> to go through all of the request handlers in the solrCore?
>
> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson <je...@gmail.com> wrote:
>> Is it possible to determine if a solr instance is a master or a slave
>> in replication terms based on the information that is placed in ZK in
>> SolrCloud?
>>
>
Re: Determining master/slave from ZK in SolrCloud
Posted by Jamie Johnson <je...@gmail.com>.
I attached my patch to do this to the JIRA at
https://issues.apache.org/jira/browse/SOLR-2765?jwupdated=55859&focusedCommentId=13122185#comment-13122185.
Any comments would be appreciated.
On Tue, Oct 4, 2011 at 1:06 PM, Jamie Johnson <je...@gmail.com> wrote:
> so my initial test worked, this appeared in ZK now
>
> roles=searcher,indexer
>
> which I can use to tell if it should be used to write to or not. It
> had fewer changes to other files as well
>
> I needed to change
> CloudDescriptor (add roles variable/methods)
> CoreContainer (parse roles attribute)
> ZKController (store roles in ZK)
>
> and now what is in ZK is the following:
>
> roles=searcher,indexer
> node_name=hostname:8983_solr
> url=http://hostname:8983/solr/
>
> As I said this will meet my need, I can provide my changes back to the
> JIRA referenced if this is what is expected from roles.
>
> On Tue, Oct 4, 2011 at 12:45 PM, Jamie Johnson <je...@gmail.com> wrote:
>> So I see this JIRA which references roles
>>
>> https://issues.apache.org/jira/browse/SOLR-2765
>>
>> I'm looking at implementing what Yonik suggested, namely in
>> solrconfig.xml I have something like
>>
>> <core name="${coreName}" instanceDir="." shard="${shard}"
>> collection="${collection}" roles="searcher,indexer"/>
>>
>> these will be pulled out and added to the cloudDescriptor so they can
>> be saved in ZK. Seem reasonable?
>>
>> On Tue, Oct 4, 2011 at 12:17 PM, Jamie Johnson <je...@gmail.com> wrote:
>>> also as an FYI I created this JIRA
>>>
>>> https://issues.apache.org/jira/browse/SOLR-2811
>>>
>>> which perhaps should be removed if the roles option comes to life. Is
>>> there a JIRA on that now?
>>>
>>> On Tue, Oct 4, 2011 at 12:12 PM, Jamie Johnson <je...@gmail.com> wrote:
>>>> Thanks for the reply Mark. So a couple of questions.
>>>>
>>>> When is distributed indexing going to be available on Trunk? Are
>>>> there docs on it now?
>>>>
>>>> I think having Roles on the shard would scratch the itch here, because
>>>> as you said I could then include a role which indicated what to do
>>>> with this server.
>>>>
>>>> My use case is actually for something outside of Solr. As of right
>>>> now we are not on the latest trunk (actually a few months back I
>>>> think) but could push to upgrade to it if the distributed indexing
>>>> code was available today, but management may still shoot that down
>>>> because of a short timeline. Suffice it to say that I'll be reading
>>>> this information by another application to handle distributed indexing
>>>> externally. The version that I'm working on requires that the
>>>> application be responsible for performing the distribution.
>>>>
>>>>
>>>> On Tue, Oct 4, 2011 at 12:05 PM, Mark Miller <ma...@gmail.com> wrote:
>>>>> Because the distributed indexing phase of SolrCloud will not use replication, we have not really gone down this path at all.
>>>>>
>>>>> One thing we are considering is adding the ability to add various roles to each shard as hints - eg a shard might be designated a searcher and another an indexer.
>>>>>
>>>>> You might be able to piggy back on this to label things master/slave. A ZooKeeper aware replication handler could then use this information.
>>>>>
>>>>> There is nothing to stop you from adding this information to zookeeper yourself, using standard zookeeper tools - but just putting the information is only half the problem - something then needs to read it.
>>>>>
>>>>> - Mark Miller
>>>>> lucidimagination.com
>>>>> 2011.lucene-eurocon.org | Oct 17-20 | Barcelona
>>>>>
>>>>> On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote:
>>>>>
>>>>>> Ok, so I am pretty sure this information is not available. What is
>>>>>> the most appropriate way to add information like this to ZK? I can
>>>>>> obviously look for the system properties enable.master and
>>>>>> enable.slave, but that won't be fool proof since someone could put
>>>>>> this in the config file instead and not as a system property. Is
>>>>>> there a way to determine this quickly programatically without having
>>>>>> to go through all of the request handlers in the solrCore?
>>>>>>
>>>>>> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson <je...@gmail.com> wrote:
>>>>>>> Is it possible to determine if a solr instance is a master or a slave
>>>>>>> in replication terms based on the information that is placed in ZK in
>>>>>>> SolrCloud?
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Determining master/slave from ZK in SolrCloud
Posted by Jamie Johnson <je...@gmail.com>.
so my initial test worked, this appeared in ZK now
roles=searcher,indexer
which I can use to tell if it should be used to write to or not. It
had fewer changes to other files as well
I needed to change
CloudDescriptor (add roles variable/methods)
CoreContainer (parse roles attribute)
ZKController (store roles in ZK)
and now what is in ZK is the following:
roles=searcher,indexer
node_name=hostname:8983_solr
url=http://hostname:8983/solr/
As I said this will meet my need, I can provide my changes back to the
JIRA referenced if this is what is expected from roles.
On Tue, Oct 4, 2011 at 12:45 PM, Jamie Johnson <je...@gmail.com> wrote:
> So I see this JIRA which references roles
>
> https://issues.apache.org/jira/browse/SOLR-2765
>
> I'm looking at implementing what Yonik suggested, namely in
> solrconfig.xml I have something like
>
> <core name="${coreName}" instanceDir="." shard="${shard}"
> collection="${collection}" roles="searcher,indexer"/>
>
> these will be pulled out and added to the cloudDescriptor so they can
> be saved in ZK. Seem reasonable?
>
> On Tue, Oct 4, 2011 at 12:17 PM, Jamie Johnson <je...@gmail.com> wrote:
>> also as an FYI I created this JIRA
>>
>> https://issues.apache.org/jira/browse/SOLR-2811
>>
>> which perhaps should be removed if the roles option comes to life. Is
>> there a JIRA on that now?
>>
>> On Tue, Oct 4, 2011 at 12:12 PM, Jamie Johnson <je...@gmail.com> wrote:
>>> Thanks for the reply Mark. So a couple of questions.
>>>
>>> When is distributed indexing going to be available on Trunk? Are
>>> there docs on it now?
>>>
>>> I think having Roles on the shard would scratch the itch here, because
>>> as you said I could then include a role which indicated what to do
>>> with this server.
>>>
>>> My use case is actually for something outside of Solr. As of right
>>> now we are not on the latest trunk (actually a few months back I
>>> think) but could push to upgrade to it if the distributed indexing
>>> code was available today, but management may still shoot that down
>>> because of a short timeline. Suffice it to say that I'll be reading
>>> this information by another application to handle distributed indexing
>>> externally. The version that I'm working on requires that the
>>> application be responsible for performing the distribution.
>>>
>>>
>>> On Tue, Oct 4, 2011 at 12:05 PM, Mark Miller <ma...@gmail.com> wrote:
>>>> Because the distributed indexing phase of SolrCloud will not use replication, we have not really gone down this path at all.
>>>>
>>>> One thing we are considering is adding the ability to add various roles to each shard as hints - eg a shard might be designated a searcher and another an indexer.
>>>>
>>>> You might be able to piggy back on this to label things master/slave. A ZooKeeper aware replication handler could then use this information.
>>>>
>>>> There is nothing to stop you from adding this information to zookeeper yourself, using standard zookeeper tools - but just putting the information is only half the problem - something then needs to read it.
>>>>
>>>> - Mark Miller
>>>> lucidimagination.com
>>>> 2011.lucene-eurocon.org | Oct 17-20 | Barcelona
>>>>
>>>> On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote:
>>>>
>>>>> Ok, so I am pretty sure this information is not available. What is
>>>>> the most appropriate way to add information like this to ZK? I can
>>>>> obviously look for the system properties enable.master and
>>>>> enable.slave, but that won't be fool proof since someone could put
>>>>> this in the config file instead and not as a system property. Is
>>>>> there a way to determine this quickly programatically without having
>>>>> to go through all of the request handlers in the solrCore?
>>>>>
>>>>> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson <je...@gmail.com> wrote:
>>>>>> Is it possible to determine if a solr instance is a master or a slave
>>>>>> in replication terms based on the information that is placed in ZK in
>>>>>> SolrCloud?
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Re: Determining master/slave from ZK in SolrCloud
Posted by Jamie Johnson <je...@gmail.com>.
So I see this JIRA which references roles
https://issues.apache.org/jira/browse/SOLR-2765
I'm looking at implementing what Yonik suggested, namely in
solrconfig.xml I have something like
<core name="${coreName}" instanceDir="." shard="${shard}"
collection="${collection}" roles="searcher,indexer"/>
these will be pulled out and added to the cloudDescriptor so they can
be saved in ZK. Seem reasonable?
On Tue, Oct 4, 2011 at 12:17 PM, Jamie Johnson <je...@gmail.com> wrote:
> also as an FYI I created this JIRA
>
> https://issues.apache.org/jira/browse/SOLR-2811
>
> which perhaps should be removed if the roles option comes to life. Is
> there a JIRA on that now?
>
> On Tue, Oct 4, 2011 at 12:12 PM, Jamie Johnson <je...@gmail.com> wrote:
>> Thanks for the reply Mark. So a couple of questions.
>>
>> When is distributed indexing going to be available on Trunk? Are
>> there docs on it now?
>>
>> I think having Roles on the shard would scratch the itch here, because
>> as you said I could then include a role which indicated what to do
>> with this server.
>>
>> My use case is actually for something outside of Solr. As of right
>> now we are not on the latest trunk (actually a few months back I
>> think) but could push to upgrade to it if the distributed indexing
>> code was available today, but management may still shoot that down
>> because of a short timeline. Suffice it to say that I'll be reading
>> this information by another application to handle distributed indexing
>> externally. The version that I'm working on requires that the
>> application be responsible for performing the distribution.
>>
>>
>> On Tue, Oct 4, 2011 at 12:05 PM, Mark Miller <ma...@gmail.com> wrote:
>>> Because the distributed indexing phase of SolrCloud will not use replication, we have not really gone down this path at all.
>>>
>>> One thing we are considering is adding the ability to add various roles to each shard as hints - eg a shard might be designated a searcher and another an indexer.
>>>
>>> You might be able to piggy back on this to label things master/slave. A ZooKeeper aware replication handler could then use this information.
>>>
>>> There is nothing to stop you from adding this information to zookeeper yourself, using standard zookeeper tools - but just putting the information is only half the problem - something then needs to read it.
>>>
>>> - Mark Miller
>>> lucidimagination.com
>>> 2011.lucene-eurocon.org | Oct 17-20 | Barcelona
>>>
>>> On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote:
>>>
>>>> Ok, so I am pretty sure this information is not available. What is
>>>> the most appropriate way to add information like this to ZK? I can
>>>> obviously look for the system properties enable.master and
>>>> enable.slave, but that won't be fool proof since someone could put
>>>> this in the config file instead and not as a system property. Is
>>>> there a way to determine this quickly programatically without having
>>>> to go through all of the request handlers in the solrCore?
>>>>
>>>> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson <je...@gmail.com> wrote:
>>>>> Is it possible to determine if a solr instance is a master or a slave
>>>>> in replication terms based on the information that is placed in ZK in
>>>>> SolrCloud?
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
Re: Determining master/slave from ZK in SolrCloud
Posted by Jamie Johnson <je...@gmail.com>.
also as an FYI I created this JIRA
https://issues.apache.org/jira/browse/SOLR-2811
which perhaps should be removed if the roles option comes to life. Is
there a JIRA on that now?
On Tue, Oct 4, 2011 at 12:12 PM, Jamie Johnson <je...@gmail.com> wrote:
> Thanks for the reply Mark. So a couple of questions.
>
> When is distributed indexing going to be available on Trunk? Are
> there docs on it now?
>
> I think having Roles on the shard would scratch the itch here, because
> as you said I could then include a role which indicated what to do
> with this server.
>
> My use case is actually for something outside of Solr. As of right
> now we are not on the latest trunk (actually a few months back I
> think) but could push to upgrade to it if the distributed indexing
> code was available today, but management may still shoot that down
> because of a short timeline. Suffice it to say that I'll be reading
> this information by another application to handle distributed indexing
> externally. The version that I'm working on requires that the
> application be responsible for performing the distribution.
>
>
> On Tue, Oct 4, 2011 at 12:05 PM, Mark Miller <ma...@gmail.com> wrote:
>> Because the distributed indexing phase of SolrCloud will not use replication, we have not really gone down this path at all.
>>
>> One thing we are considering is adding the ability to add various roles to each shard as hints - eg a shard might be designated a searcher and another an indexer.
>>
>> You might be able to piggy back on this to label things master/slave. A ZooKeeper aware replication handler could then use this information.
>>
>> There is nothing to stop you from adding this information to zookeeper yourself, using standard zookeeper tools - but just putting the information is only half the problem - something then needs to read it.
>>
>> - Mark Miller
>> lucidimagination.com
>> 2011.lucene-eurocon.org | Oct 17-20 | Barcelona
>>
>> On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote:
>>
>>> Ok, so I am pretty sure this information is not available. What is
>>> the most appropriate way to add information like this to ZK? I can
>>> obviously look for the system properties enable.master and
>>> enable.slave, but that won't be fool proof since someone could put
>>> this in the config file instead and not as a system property. Is
>>> there a way to determine this quickly programatically without having
>>> to go through all of the request handlers in the solrCore?
>>>
>>> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson <je...@gmail.com> wrote:
>>>> Is it possible to determine if a solr instance is a master or a slave
>>>> in replication terms based on the information that is placed in ZK in
>>>> SolrCloud?
>>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
Re: Determining master/slave from ZK in SolrCloud
Posted by Jamie Johnson <je...@gmail.com>.
Thanks for the reply Mark. So a couple of questions.
When is distributed indexing going to be available on Trunk? Are
there docs on it now?
I think having Roles on the shard would scratch the itch here, because
as you said I could then include a role which indicated what to do
with this server.
My use case is actually for something outside of Solr. As of right
now we are not on the latest trunk (actually a few months back I
think) but could push to upgrade to it if the distributed indexing
code was available today, but management may still shoot that down
because of a short timeline. Suffice it to say that I'll be reading
this information by another application to handle distributed indexing
externally. The version that I'm working on requires that the
application be responsible for performing the distribution.
On Tue, Oct 4, 2011 at 12:05 PM, Mark Miller <ma...@gmail.com> wrote:
> Because the distributed indexing phase of SolrCloud will not use replication, we have not really gone down this path at all.
>
> One thing we are considering is adding the ability to add various roles to each shard as hints - eg a shard might be designated a searcher and another an indexer.
>
> You might be able to piggy back on this to label things master/slave. A ZooKeeper aware replication handler could then use this information.
>
> There is nothing to stop you from adding this information to zookeeper yourself, using standard zookeeper tools - but just putting the information is only half the problem - something then needs to read it.
>
> - Mark Miller
> lucidimagination.com
> 2011.lucene-eurocon.org | Oct 17-20 | Barcelona
>
> On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote:
>
>> Ok, so I am pretty sure this information is not available. What is
>> the most appropriate way to add information like this to ZK? I can
>> obviously look for the system properties enable.master and
>> enable.slave, but that won't be fool proof since someone could put
>> this in the config file instead and not as a system property. Is
>> there a way to determine this quickly programatically without having
>> to go through all of the request handlers in the solrCore?
>>
>> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson <je...@gmail.com> wrote:
>>> Is it possible to determine if a solr instance is a master or a slave
>>> in replication terms based on the information that is placed in ZK in
>>> SolrCloud?
>>>
>
>
>
>
>
>
>
>
>
>
>
>
Re: Determining master/slave from ZK in SolrCloud
Posted by Mark Miller <ma...@gmail.com>.
Because the distributed indexing phase of SolrCloud will not use replication, we have not really gone down this path at all.
One thing we are considering is adding the ability to add various roles to each shard as hints - eg a shard might be designated a searcher and another an indexer.
You might be able to piggy back on this to label things master/slave. A ZooKeeper aware replication handler could then use this information.
There is nothing to stop you from adding this information to zookeeper yourself, using standard zookeeper tools - but just putting the information is only half the problem - something then needs to read it.
- Mark Miller
lucidimagination.com
2011.lucene-eurocon.org | Oct 17-20 | Barcelona
On Oct 4, 2011, at 10:26 AM, Jamie Johnson wrote:
> Ok, so I am pretty sure this information is not available. What is
> the most appropriate way to add information like this to ZK? I can
> obviously look for the system properties enable.master and
> enable.slave, but that won't be fool proof since someone could put
> this in the config file instead and not as a system property. Is
> there a way to determine this quickly programatically without having
> to go through all of the request handlers in the solrCore?
>
> On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson <je...@gmail.com> wrote:
>> Is it possible to determine if a solr instance is a master or a slave
>> in replication terms based on the information that is placed in ZK in
>> SolrCloud?
>>
Re: Determining master/slave from ZK in SolrCloud
Posted by Jamie Johnson <je...@gmail.com>.
Ok, so I am pretty sure this information is not available. What is
the most appropriate way to add information like this to ZK? I can
obviously look for the system properties enable.master and
enable.slave, but that won't be fool proof since someone could put
this in the config file instead and not as a system property. Is
there a way to determine this quickly programatically without having
to go through all of the request handlers in the solrCore?
On Mon, Oct 3, 2011 at 5:52 PM, Jamie Johnson <je...@gmail.com> wrote:
> Is it possible to determine if a solr instance is a master or a slave
> in replication terms based on the information that is placed in ZK in
> SolrCloud?
>